[ENBD] Ammended setup: -> what would happen if...

Peter T. Breuer enbd@lists.community.tummy.com
Sun, 20 Apr 2003 18:59:31 +0200 (MET DST)


"A month of sundays ago Liam Helmer wrote:"
> Sorry, I was unclear -> the raid was from client to server, to deal with 
> network disconnections and server reboots.

Raid can be either clientside or serverside.  The above sentence leaves
me hanging as to which you mean!  Let's assume "clientside"?

> OK, cool. It looks like, since you're no longer doing the remote to 
> local mirroring in enbd, I'll have to check into RAID-1 for the answers 

I thought I explained in my previous message. There is no "local to
remote" mirroring in enbd, but 2.4.31 does have a raid1-like feature
that amounts to clientside raid1 amongst enbd connections. That support
has moved outside of the enbd driver and should now be done by
ordinary raid1 over enbd, and indeed must be done by ordinary raid1
if you want a local miror. If you use the fr1 driver (freshmeat)
then disconnect and reconnect is automatic, and it will do an
intelligent (minimal) resync too.

> -> this is no longer an enbd question. Which should make answers more 
> clear. I'd probably have to do a userspace synch: you're right, that I 

Userspace sync should not be necessary - that is what raid1 does.

> should be just looking at this as a hard disc. What I was most 
> interested in is what behaviour the raid would exhibit... From this 
> case, what I think is that the raid is going to take the most recently 

I'm not sure what you mean. A raid1 mirror of two components, in which
one has failed, continues using the other component. When the failed
component is replaced, then the replacement is synced in the background
from the good component. In fr1 (as opposed to raid1) that resync is
intelligent, only consisting of blocks that have been updated locally
but not remotely. In fr1 the replacement is automatic too. In no
scenario do you do any resync manually.

> synched superblock and give it precedence... but won't integrate the two 
> except with a manually issued command. Which is the best case scenario 
> for me -> I can't deal with a suddenly corrupted disc very well, but I 
> can create a userspace tool to perform a resynch of the raid.

Raid is always resynced by the raid driver. That's much of the the point!

> Which makes me think that I've got this setup totally wrong for the 
> application -> I need to be doing the mirroring from the filesystem 
> layer or on top of it, rather than at the bottom level. So, maybe using 

I'm not sure what you mean... you can either mirror at the filesystem
level or at the block level. There are advantages and disadvantages to
both. Omirr is the standard fs mirroring solution, I think.

> coda, which has some automatic caching features, or just a simpler rsych 
> type setup... where the cache is also on an encrypted volume. And, I 
> need to get some way of effectively failing the disks without crashing 
> the client. No really easy solution comes to mind though.

I'm not sure what you mean .. if you are looking a failover, the distro
comes with heartbeat scripts to do it (let me know of any problems :-).

Peter