Iustin Pop wrote:

On Sun, Aug 12, 2007 at 07:03:44PM +0200, Jan Engelhardt wrote:

quoted

On Aug 12 2007 09:39, david@lang.hm wrote:

quoted

now, I am not an expert on either option, but three are a couple things that I
would question about the DRDB+MD option

1. when the remote machine is down, how does MD deal with it for reads and
writes?

I suppose it kicks the drive and you'd have to re-add it by hand unless done by
a cronjob.

Yes, and with a bitmap configured on the raid1, you just resync the 
blocks that have been written while the connection was down.

quoted

From my tests, since NBD doesn't have a timeout option, MD hangs in the

write to that mirror indefinitely, somewhat like when dealing with a
broken IDE driver/chipset/disk.

Well, if people would like to see a timeout option, I actually coded up 
a patch a couple of years ago to do just that, but I never got it into 
mainline because you can do almost as well by doing a check at 
user-level (I basically ping the nbd connection periodically and if it 
fails, I kill -9 the nbd-client).

quoted

quoted

2. MD over local drive will alternate reads between mirrors (or so I've been
told), doing so over the network is wrong.

Certainly. In which case you set "write_mostly" (or even write_only, not sure
of its name) on the raid component that is nbd.

quoted

3. when writing, will MD wait for the network I/O to get the data saved on the
backup before returning from the syscall? or can it sync the data out lazily

Can't answer this one - ask Neil :)

MD has the write-mostly/write-behind options - which help in this case
but only up to a certain amount.

You can configure write_behind (aka, asynchronous writes) to buffer as 
much data as you have RAM to hold. At a certain point, presumably, you'd 
want to just break the mirror and take the hit of doing a resync once 
your network leg falls too far behind.

--
Paul