Subject: Re: raidframe, cgd and parity errors
To: Daniel Carosone <email@example.com>
From: theo borm <firstname.lastname@example.org>
Date: 05/04/2005 12:14:01
Daniel Carosone wrote:
>On Wed, May 04, 2005 at 09:37:14AM +0200, theo borm wrote:
>>In a stock 2.0.2 install with a GENERIC+CGD kernel, whenever a cgd is
>>run on top of a raidrame device this results in parity errors on every
>To be clear, you mean that the RF parity is marked 'dirty', not that
>there are actually *errors*, right?
>>OR if there would be a "cgdconfig -l" listing the configured cgd(s)
>>(see PR 20767)
>It might be handy to have this, but you can get this info more
>generally from sysctl hw.disknames
Great. That's at least part of the solution ;-)
>>Questions that remain are:
>>1) /Why/ does parity get dirty when at shutdown time a cgd is configured
>>on top of a raidframe device?.
>Because RF writes out a parity-clean status to disk only on last
>close, and the cgd keeps it open. The same happens for swap-to-RF
>unless you run shutdown hooks to remove that.
So I guess that all devices that might run on top of another device
those. Then, at least, if then the default installed rc.d scripts manage to
configure a particular setup automatically, then the unconfiguration
would also be automatic.
>>3) (On a more general level) The (rcorder) way of handling cgd(s) on top
>>of raidframe devices happens to be the correct one for my situation, but
>>will (should) fail if raidframe needs to be run on top of cgd(s) (....),
>>or if a cgd is run on top of a ccd (or any other order of stacking multiple
>>devices with a (partial) /alphabetical/ order in their device names). Any
>>thoughts about taking these out of rcordered rc.d and building a proper
>>set of dependencies (make disk-dependencies?) Of course one /could/ add
>>disk1, disk2 ... disk3 levels to the rc.d scripts, but would that be more
>>than a hack?
>There are some things you can do here within the generic framework,
>but at some point you have special, unique requirements and have to
>implement them yourself. The rc.d framework makes fitting these
>customisations in with the system-supplied stuff very easy.
I guess you are right; making system administrators' life easier is not a
kernel programmers' main raison d'etre ;-)
Kernel raidframe seems to be able to figure out what filing systems are
mounted on top of it, and cleanly "unconfigures" those before writing
parity clean status. Presumably it also does this for /some/ devices:
over raidframe apparently (?) works. Also, I've not seen any complaints
ffs on cgd on vnd on NFS exported RF volumes.....
Catering, during shutdown, explicitly for every possible permutation of
device and filing system on top of each other would be a proverbial pain if
done through rc.d scripts, however, I imagine that if I could somehow obtain
the device/fs interdependency information, I could automate this rather
in a single script....
Is it possible to obtain for every device/filesystem the underlying
filing system(s), so that I can dynamically build a tree (mesh)?
with kind regards, Theo