*BSD News Article 31102


Return to BSD News archive

Newsgroups: comp.os.386bsd.bugs
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!howland.reston.ans.net!europa.eng.gtefsd.com!MathWorks.Com!news.duke.edu!concert!sas!mozart.unx.sas.com!torpid.unx.sas.com!sastdr
From: sastdr@torpid.unx.sas.com (Thomas David Rivers)
Subject: Re: serious fsck bug
Sender: news@unx.sas.com (Noter of Newsworthy Events)
Message-ID: <Cqo6K2.Hr0@unx.sas.com>
Date: Tue, 31 May 1994 13:52:50 GMT
References: <NILS.94May28022525@guru.stgt.sub.org> <J88NWK-.dysonj@delphi.com> <NILS.94May29133633@guru.stgt.sub.org>
Nntp-Posting-Host: torpid.unx.sas.com
Organization: SAS Institute Inc.
Lines: 43

In article <NILS.94May29133633@guru.stgt.sub.org> nils@ims.uni-stuttgart.de writes:
>In article <J88NWK-.dysonj@delphi.com> John Dyson <dysonj@delphi.com> writes:
>
>> Are you getting I/O errors sometimes during the operation of your system.  
>> The UFS filesystem can get really messed up if the metadata is not updated
>> properly.  BTW, after making your backup, have you tried to remake the
>> the offending filesystem?????
>
>I do not get any error while using the drive. And yes, after backing
>up the data I remade the filesystems with different numbers of inodes
>and minfree (5 or 10%). I backed up and restored the data using
>dump/restore and tar. Again: all operations complete without any
>error. But nothing helped so far, fsck still complains.
>
>After spending one day to repair my filesystems I managed to heal one
>of them. Lets concentrate on the other: fsck tells me the same things
>all over again: unknown file types, partially allocated inodes, bad
>indirect blocks (looks like random huge postitive or negative
>numbers), duplicated blocks, bad link counts of files (the link count
>should be negative!! could there be a sanity check in fsck, please?)
>and never ever cleans/removes/reconnects them. The next run of fsck
>results in the same errors.
>
>After writing a small 'unlink' utility I detected the clri command
>which supposedly zeros out a given inode. Using this didn't help, the
>offending inodes still contained their meaningless data.
>
>So, is this a problem of my disk, the kernel, fsck? 

  Every time I've encountered this problem (even with SCSI drives) there
has been a hardware fault lurking around.

  I always begin with checking the cabling; then, if the disk isn't
SCSI or IDE; I set up a new bad144 entry.  Also, a low-level format
(even for SCSI drives) can really help with this problem (for SCSI,
the bad sectors will be remapp'd during the format.)

  If this doesn't work; I go out and buy a new disk.

	- Dave Rivers -
	(sastdr@unx.sas.com)
-- 
Imagine Whirled Peas.