*BSD News Article 49830


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!news.sprintlink.net!howland.reston.ans.net!swrinde!elroy.jpl.nasa.gov!lll-winken.llnl.gov!fnnews.fnal.gov!nntp-server.caltech.edu!news.cerf.net!taxis.corp.titan.com!usenet
From: ss@tisc.com (Steve Schossow)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: FreeBSD2.0 Clean Flag in Superblock
Date: Fri, 25 Aug 1995 01:32:08 GMT
Organization: The Titan Corporation, San Diego, CA, USA
Lines: 58
Message-ID: <41j96n$1nq@taxis.corp.titan.com>
References: <41bl3c$81q@mippet.ci.com.au> <41d905$35v@blob.best.net> <41e49a$3lm@reason.cdrom.com>
NNTP-Posting-Host: ss.bc.tisc.titan.com
X-Newsreader: Forte Free Agent v0.55

"Jordan K. Hubbard" <jkh@FreeBSD.org> wrote:

>dillon@best.com (Matt Dillon) wrote:
>>    I've never quite understood why that fsck is in there.  At best you
>>    would get information on the fragmentation on the drive out of it.

>Neither did we, which is why that fsck is no longer in there... :-)

>-- 
>						Jordan

Using fsck -n and filtering the messages could be beneficial.  Jump to
the end of my post for the point I'm trying to make... or read my
(long) story of fsck -n.

===========

I've found interesting results running fsck -n on a machine that was
having an IDE disk slowly dying.  The fsck -n in /etc/daily gives
various messages about unreferenced files (which seem benign) but as
the disk got sick, fsck started complained about BAD/DUP inodes and
UNKNOWN FILE TYPES corresponding to the BAD/DUP inode numbers.

I ignored the messages as I also had read on the *bsd newsgroups that
the fsck was bogus.  BUT...

The machine kept running until some part of /usr/lib got lost and I
couldn't start vi on a file.  I found out that
/usr/lib/libcurses.so.1.1 and a BUNCH of other parts of /usr/lib were
0-length files (the message from vi was something like 'couldn't find
libcurses').  I got worried but wasn't sure what to do.

I ran my script which tar's /etc, /users, and parts of /var and ftp-ed
it to another machine for safe-keeping.  I connected via slip from
home later that night and found more stuff missing from the
filesystem.  Files seemed to be dropping off before my eyes as I ran
sync; sync; sync; fsck -n.  By 4:00 AM the machine couldn't be
telnet-ed or ftp-ed into, only a console login worked.  When I got
back to work I tried to reboot and it wouldn't boot.

I put a fresh IDE disk in (no flames please!) and did a new install.
Then I untarred my saved data over /etc, /users and /var and
re-booted.  I had lost a couple of users files and some mail but other
than that the machine was reborn.  Talk about a studly O/S!!!  This
thing didn't know it had congestive heart failure and just kept
running until it had nothing left to run on.

My point being that running fsck -n and piping the output through grep
could catch an impending problem if one picks the 'serious' messages.
Not being an expert in ffs, the only nasty messages I've seen are
BAD/DUP and the UNKNOWN FILE TYPE.  YMMV.

Just my $0.02.

Regards,
Steve Schossow <ss@tisc.com>