GSOC: Device mapper mirror target

Alex Hornung ahornung at gmail.com
Mon Apr 25 02:33:56 PDT 2011


On 25/04/11 10:15, Adam Hoka wrote:
>> I also don't see the need of delegating every write to secondary mirror
>> legs to a thread. You definitely need a synchronization thread, but I
>> think you should propagate writes to each of the mirror disks from the
>> same context you are in when you get the requests.
> 
> That "thread" could be a workq (which will run in a different thread,
> obviously).

I know what you mean, but I don't see why you would do it like that. You
should be dispatching writes to all the mirror disks immediately and not
queue them to later dispatch them for a different thread. I see no
advantage to that approach, it makes things more complicated and last
but not least it is also less robust.

>> You mention in your proposal the following:
>> "Week 8-9: Write feature tests and fix any issues encountered, test LVM
>> snapshoting".
>> How is that related to the project? Am I missing something?
> 
> The mirror target is used to sync snapshot, so yes it is highly related.
> My main motivation to write the mirror target support is to enable
> snapshoting (this is also the reason why did my original proposal aimed
> to provide less data consistency, altough now I realize that most people
> would like to use the mirror target as a general RAID-1 implemtation).

I'm still not sure how the mirror would work with LVM snapshots. AFAIK
linux has a snapshot device mapper target to support that and I still
don't see where the mirroring fits in.

And yea, what we want out of this GSoC project is a good RAID-1 / mirror
implementation. We have vinum, but it is overcomplicated and outdated,
so the idea is to have a nice and clean RAID1 implementation as a device
mapper target. Robustness/data consistency is pretty much a top priority
for this. Performance can be improved using NCQ/TCQ features whenever
the design works.


> I cant update the proposal, I think. This melange is a bit confusing... :-)

It doesn't matter, no need to update the proposal. Take it as a "if you
are selected, I think you should..." discussion.

Regards,
Alex Hornung





More information about the Kernel mailing list