Dear list members,

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.

Now, I figured out a work-around at shutdown-time that will prevent
these problems:
1) unmount all filesystems mounted on the cgd(s)
2) unconfigure the cgd(s)

This shutdown sequence /can/ be (sort of) automated in the /etc/rc.d/cgd
script by parsing mount output (| grep | cut), unmounting all mounted
cgd devices, and then doing a cgdconfig -U. This is, however a hack that
does not cater for cgd(s) not mentioned in /etc/cgd/cgd.conf because
their configuration at boot time is unwanted. For a more structured
approach to this particular problem, it would be nice if /either/
cgdconfig -U would also unmount the filing systems (is that reasonable?)
OR if there would be a "cgdconfig -l" listing the configured cgd(s)
(see PR 20767) (actually better because it would cater for cgd(s) not
in /etc/cgd/cgd.conf).

Questions that remain are:
1) /Why/ does parity get dirty when at shutdown time a cgd is configured
on top of a raidframe device?.
2) Does the raidframe driver contain any knowkledge about filesystems and
devices that might live on top of it?
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?

with kind regards,

Theo Borm