Subject: Re: raidframe, cgd and parity errors
To: Daniel Carosone <firstname.lastname@example.org>
From: theo borm <email@example.com>
Date: 05/04/2005 13:43:46
Daniel Carosone wrote:
>On Wed, May 04, 2005 at 12:14:01PM +0200, theo borm wrote:
>>Kernel raidframe seems to be able to figure out what filing systems are
>>mounted on top of it, and cleanly "unconfigures" those before writing
>>out the parity clean status.
>Not at all; the kernel unmounts all filesystems, and then RF writes
>out its parity clean status on last device close.
>You just need to arrange for non-filesystem users of RF devices to
>also let go of them in time; cgd, swap, stacked raid, etc.
Hmm... the kernel unmounts the whatever is mounted on cgds
only after /rc.d/cgd has gotten the opportunity to unconfigure its
devices, which of course fails if filing systems are not first
dismounted, which transfers the hassle of properly unmounting
FS's to a rc.d script, where it doesn't belong :-/
There is just one other point that bothers me: just having a cgd
*configured* (i.e. not having mounted filesystems on top of them)
causes the parity to be dirty.... Does this mean that somewhere
(in the kernel) CGD gets shut down /after/ RF, causing the cgd
driver to write updates to the underlying disks (I hope not) (and if:
how?), OR does that mean that RF refuses to write the parity clean
status when some of the devices it exports are still being used
(more logical, but a message would have been welcome).
>Perhaps we could add an 'unconfigure-on-last-close' to cgd, or to
>wedges more generally later. A generic mechanism to publish stacking
>tree information probably also belongs as part of wedges.