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