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
>>reboot.
>>    
>>
>
>To be clear, you mean that the RF parity is marked 'dirty', not that
>there are actually *errors*, right?
>  
>
Exactly.

>>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 
should have
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 
out the
parity clean status. Presumably it also does this for /some/ devices: 
raidframe
over raidframe apparently (?) works. Also, I've not seen any complaints 
about
ffs on cgd on vnd on NFS exported RF volumes.....

Catering, during shutdown, explicitly for every possible permutation of 
block
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 
easily
in a single script....

Is it possible to obtain for every device/filesystem the underlying 
device(s)/
filing system(s), so that I can dynamically build a tree (mesh)?

with kind regards, Theo