Subject: Re: Playing with dkwedge
To: Manuel Bouyer <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 08/24/2005 12:37:51
Content-Type: text/plain; charset=us-ascii
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:
> > 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
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
What options are those? I do not see them in our dump(8).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----