Subject: Re: Disk Corruption Problems!
To: , <port-mac68k@netbsd.org>
From: John Klos <john@sixgirls.org>
List: port-mac68k
Date: 09/02/2001 03:20:59
Hello,

> I have a Quadra 605 (aka LC 475) with NetBSD 1.5.1 installed. I keep
> encountering what seem like constant disk corruption problems. When the
> computer is running, there seemed to be no problems... I turned on the
> check_fsck option in rc.conf. Every morning (about 3am), the computer
> performs fsck on the hard drives.

Q605s are great little machines. I have several.

What option are you talking about when you say you've enabled check_fsck?
I am unaware of any such option, and only see the standard fsck script in
/etc/rc.d/

> It seems the hard drives gets corrupted pretty often--with no apparant
> reason. Most often, there are complaints of obsessive DUP blocks. Other
> than that, there are also often unreferenced inodes, that was cleared
> during fsck.

> What is even stranger, when I do fsck in multiuser mode, it does not
> seem to fix the problem. Obviously, I cannot remount the disk as
> read-only(root partition). So I tried to clear all disk operations using
> sync. First run of fsck appeared to fix all the problems, but successive
> fsck runs show up the exact same problems. However, when I reboot the
> system into single user mode, then do another fsck--the same problem
> disappeared.
>
> Although there appears to be no data loss (all the vital data are stored
> in another hard drive, which  almost always checked out ok), the fact
> that these errors appears on my logs is disturbing.
>
> Any idea what is the cause of this?

The most obvious problem is doing fsck's on live filesystems. When a
filesystem is checked while read-write, it can be changed while fsck is
running, which can cause fsck to think there are problems when there are
not.

Also, unless you unmount and remount a filesystem, you should not use it
after doing a fsck; the system should be rebooted before use.

I bet if you fsck in single user mode and reboot you'll not have any
filesystem problems any more.

John Klos