Re: GSOC: Device mapper mirror target

[Alex Hornung <ahornung@xxxxxxxxx>]

Hi,

I'm a bit late to comment here, but I have been pretty busy. As
Venkatesh has already said, it is important to note that it's not like
we simply biodone() I/Os that are not done yet, what actually happens is
that the disk says that a request is done even if it isn't.

Another bit that I think you missed is that our I/O system revolves
around struct bio and not struct buf as NetBSD's does. Strategy routines
for example accept bios (except for dm's :)).

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.

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?

As Venkatesh mentioned, too, your design needs to meet certain
reliability requirements. Just blindly sending I/Os off left and right
and hoping for them to hit the disk is not an option. You should provide
some more implementation details on how you intend to make your approach
reliable; when and how you write to the log/bitmap/... for example. I'd
also like you to take a look, maybe during the last few weeks, at more
advanced topics that are likely to help this aspect such as NCQ/TCQ
write barriers.

As a final note you should familiarize yourself with our dm code and
other bits and pieces ahead of week 1 ("Week 1: Understanding the device
mapper code and how the mirror thread should interact with it and
existing raid1 implementations (including Linux dm)"). That is what the
"community bonding period" should be used for.

Regards,
Alex