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

On Tue, Aug 23, 2005 at 02:51:54PM +0200, Manuel Bouyer wrote:
> On Mon, Aug 22, 2005 at 04:51:49PM -0700, Bill Studenmund wrote:
> > > I'd still like to see a fsck -n run in the daily script on journaled =
> > > system. Usefull to detect corruption (the daily fsck -n has already p=
> > > me hardware problems before they became too bad).

Are you looking for hardware issues of file system issues? I'm confused.

> > I think a better solution to this is to run a background scrubber scrip=
> > All you need to do is read data, you don't need to calculate bitmaps &=
> > such. And it'd also be good to read raw data areas, not just metadata=
> > areas.
> >=20
> > Such a tool would help with the reliability of RAID 5 systems and keep =
> > disk failure from turning into a fatal double error (finding a bad bloc=
> > when one disk is down).
> This would be good to have too, but it doesn't remplace a periodic consis=
> check of the filesystem. In one case where this helped me, it was the
> drive which was returning bogus data sometimes (I suspect its internal
> cache memory was bad, or something like that). The system would end up=20
> panicing in the fileystem code, but the daily fsck showed the problem bef=
> the panic occured.

The problem is that if the file system is live, you may always get issues.=
A journaled file system will have them even more so than a non-journaled=20
one. So how do we tell one type of error from another in the complaints of=
a screaming fsck -n?

While you may be able to tell the difference, I don't see how this step=20
will be helpful in general if we can't explain what to do to new=20

Take care,


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

Version: GnuPG v1.2.3 (NetBSD)