Subject: Re: raidframe, cgd and parity errors
To: None <tech-kern@netbsd.org>
From: Daniel Carosone <dan@geek.com.au>
List: tech-kern
Date: 05/04/2005 19:19:43
--WdPYQQQ4lIWZ4ZWi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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?

> 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)

Yup.

> 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

> 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.

> 2) Does the raidframe driver contain any knowkledge about filesystems and
> devices that might live on top of it?

No, nor should 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?

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.

--
Dan.

--WdPYQQQ4lIWZ4ZWi
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (NetBSD)

iD4DBQFCeJOuEAVxvV4N66cRAiMVAJUW4skrPWEcr85xWR/Kp7fkvWN9AKDbYdL8
HzSirXeZkWgpLfXxYc7OAQ==
=8h2b
-----END PGP SIGNATURE-----

--WdPYQQQ4lIWZ4ZWi--