Subject: Re: Playing with dkwedge
To: Manuel Bouyer <>
From: Bill Studenmund <>
List: tech-kern
Date: 08/24/2005 12:37:51
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 24, 2005 at 12:33:29PM +0200, Manuel Bouyer wrote:
> On Tue, Aug 23, 2005 at 02:57:37PM -0700, Jason Thorpe wrote:
> >=20
> > A periodic check of a journaled file system only buys you something =20
> > if the file system is quiescent.  Otherwise, it will appear largely =20
> > inconsistent.
> Isn't this what snapshots are for ?

Yes and no. That's what softdeps uses snapshots for, or one of the things=
it uses them for. However snapshots are more for being able to make=20
self-consistent backups and for simple "undelete" (deleted something by=20
mistake? Chances are it's in the snapshot, so just bring it back).

The problem I see with what you're proposing, using fsck as a disk=20
reliability verification tool, is that that's not what it was designed=20
for. While I do not doubt that it really really helped you, I do not think=
we should make this a recomended practice.

If you (or I) really care about the data, we should be using a RAID 5 or=20
better. And we should have a program that verifies parity. Not just reads=
the whole disk, but verifies each stripe's parity. Run it say once a week=
on the whole array, and things are good.

The problem with fsck is that you really just got lucky. fsck wouldn't=20
notice if the cache messed up reading file data. It also won't really=20
notice (AFAICT) if it gets passed incorrect-but-sensible-looking data at=20
certain points.

So if we want to do something, let's use the right tool for it.

> BTW, we should probably add the -x and -X options to fsck, similar to
> dump(8).

What options are those? I do not see them in our dump(8).

Take care,


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

Version: GnuPG v1.2.3 (NetBSD)