Re: GSOC: Device mapper mirror target

[Adam Hoka <adam.hoka@xxxxxxxxx>]

On Mon, 25 Apr 2011 07:12:44 +0100
Alex Hornung <ahornung@gmail.com> wrote:

> 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.

Yes, I have already realized that. :-)

> 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 only checked the dm sources in dragonfly, so I missed it. I just read the
struct bio paper, thanks.

> 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).

> 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).

> 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.

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

> 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.

I didn't know that, thanks. I made a lot of research when I was asked
to make make proposal more verbose.

> Regards,
> Alex


-- 
NetBSD - Simplicity is prerequisite for reliability