I was giving vinum + softupdates a bit of a workout on 4 really old
SCSI disks (Sun shoeboxes, if you must know) attached to an aha1542B.
The rest of the machine is a Pentium 133 with 64MB of parity ram, a
few more disks, and another aha1542B. It runs -current (about 10 days
old now).
I was copying a newer -current source tree onto the box when I lost power
to my house for maybe half a second. Being foolish and shortsighted, I
have no UPS. (An interesting side note: out of the 3 machines in use at
the time, 2 of the keyboards locked up and required a power down to recover.
I was unaware that keyboards could crash.)
When the system came back up, fsck -p didn't like the vinum volume.
No sweat, I ran it manually. There were many
INCORRECT BLOCK COUNT I=<n> (4 should be 0)
messages. I assumed this was an artifact of soft updates. The fsck
completed successfully.
Being paranoid, I reran fsck. This time it reported a number of
unreferenced inodes (199 to be exact), and linked them in to lost+found.
It is this last item that bothers me. When the first fsck completed,
the filesystem should have been structurally correct. But it wasn't.
A third fsck confirmed that 2 runs of fsck were enough.
I seem to recall sagely advice from days gone by to always run fsck twice
and sync thrice. I thought I could forget all that stuff nowadays.
By the way, I saved the broken old source tree and compared it to the
full tree. There were no unusual differences, except for the broken
one being incomplete. So, if fsck were a little better, things would
be fine. As good as you could expect, given a power failure.
Stephen.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
