Jim Reid <jim@mpn.cp.philips.com> wrote:
> Personally, I prefer O'Reilly's set of the BSD manuals. If you're a
> novice to UNIX sysadmin,

I don't think I'm a novice anymore. I've learnt by experience,
though, and since disks don't die very often, I don't have much
experience with dealing with that.

>     Jon> You are joking, I presume? "DUP/BAD", "BAD" "EXCESSIVE DUP
>     Jon> BLKS" aren't all that comprehensible to me. I know vaguely
>     Jon> how the ffs filesystem works (or at least, I did. I've mostly
>     Jon> forgot).
> 
> "DUP" is short for duplicated, same as in the system call. "BAD" is
> short for bad - the opposite of good. "BLKS" is short for blocks. (blk
> is a common abbreviation for block in UNIX kernel/user code.) Seems
> pretty clear to me so far.

I worked that much out by myself ;-). What it doesn't tell you
is what it actually *means*. I think an 'explain' button would be
rather useful at the yes/no prompts.

> If you *still* want chapter and verse, consult the guide in
> /usr/share/doc/smm.

Am doing ;-).

>     Jon>  fsck could be a lot more helpful than it is.
> 
> I suppose so, if you like chatty programs. OTOH, if you think like a
> moron - I'm not suggesting you are - fsck *very* helpful. It could
> hardly be more helpful.

It just seems perverse to use abbreviations like "BLKS" for "blocks".
They add a bit of obfuscation for absolutely no gain. And even
a single line for each message saying what will actually *happen*
if you say yes or no (e.g. "this will lose the data contained
within the named file") would be nice.

> This doesn't make sense. If the files were removed and their inodes
> cleared on the first fsck, there would be nothing for the second to
> recover as the relevant filesystem metadata would have been zeroed on
> disk. Perhaps some files were removed first time round because of the
> dup/bad blocks and some of those files were directories? If that was
> the case, the first run of fsck will have patched up the mangled
> directories as best it could, perhaps simply by deleting them. The
> second fsck would find all the files orphaned as a result of the
> corrupted directories getting cleared.

It didn't mention anything about corrupted directories though.
The files it asked whether to remove on the first run it re-created
on the second. (The files match up.) I don't trust it, personally,
since it destroyed our 2GB disk the other week (minor corruption,
run fsck -> no data left).

> Looks like you've been very unlucky. This is why sync, shutdown and
> dump are the system administrator's best friends..... and fsck for
> that matter... :-)

Hmm, 'dump' is your friend only so long as undocumented
misfeatures don't mean it silently creates unusable
backups... but we've been here already ;-).

Cheers


Jon
____
\  //    Jon Ribbens    //
 \// jon@oaktree.co.uk //