*BSD News Article 49608


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!agate!howland.reston.ans.net!newsfeed.internetmci.com!news.mathworks.com!fu-berlin.de!zrz.TU-Berlin.DE!zib-berlin.de!news.tu-chemnitz.de!irz401!not-for-mail
From: hohmuth@irs.inf.tu-dresden.de (Michael Hohmuth)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: 2.0.5R: bad inodes once a week...
Date: 29 Aug 1995 18:56:56 +0200
Organization: Dept. of Computer Science, TU Dresden, Germany
Lines: 101
Message-ID: <41vgso$pk0@irzr17.inf.tu-dresden.de>
Reply-To: hohmuth@inf.tu-dresden.de
NNTP-Posting-Host: irs.inf.tu-dresden.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Once in a week or so, my daily "fsck -n" run reports truncated and/or
bad inodes and unreferenced files which don't go away when rebooting
and which need to be cleared by hand.  These are not caused by
crashes.  I'll append an example `fsck' output after my .sig.

I wonder whether this is a kernel bug or a hardware problem.  I'm
tempted to assume the first because I didn't find any suspicious
messages on the console and in /var/log/messages.

Is it possible that FreeBSD has problems with truncating files on
large partitions?  The partition this is happening with is 1 GB big
(it's the only partition of the FreeBSD system).

This is on an ASUS SP3G + i486DX4 with the SCSI disk attached directly
to the motherboard's NCR53c810 controller.  The machine is running
2.0.5-RELEASE.

Thanks in advance for any helpful hints for fixing or further tracking
down the problem!

Michael
-- 
Email: hohmuth@inf.tu-dresden.de
WWW:   http://www.inf.tu-dresden.de/~mh1/

------------------------------------------------------------------------------

** /dev/rsd0a (NO WRITE)
** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
PARTIALLY TRUNCATED INODE I=180124
SALVAGE? no

423867417 BAD I=180124
-1273412684 BAD I=180124
1135876419 BAD I=180124
423867417 BAD I=180124
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
UNREF FILE  I=9994  OWNER=sr1 MODE=100644
SIZE=593 MTIME=Aug 28 21:16 1995 
RECONNECT? no


CLEAR? no

UNREF FILE  I=153262  OWNER=sr1 MODE=100644
SIZE=1414 MTIME=Aug 28 20:47 1995 
RECONNECT? no


CLEAR? no

UNREF FILE  I=175527  OWNER=sr1 MODE=100644
SIZE=8490 MTIME=Aug 28 21:03 1995 
RECONNECT? no


CLEAR? no

BAD/DUP FILE I=180124  OWNER=sr1 MODE=100644
SIZE=126629 MTIME=Aug 28 21:06 1995 
CLEAR? no

UNREF FILE  I=184335  OWNER=sr1 MODE=100644
SIZE=3259 MTIME=Aug 28 21:15 1995 
RECONNECT? no


CLEAR? no

UNREF FILE  I=202484  OWNER=sr1 MODE=100644
SIZE=407 MTIME=Aug 28 21:16 1995 
RECONNECT? no


CLEAR? no

UNREF FILE  I=238524  OWNER=sr1 MODE=100644
SIZE=477 MTIME=Aug 28 21:16 1995 
RECONNECT? no


CLEAR? no

** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? no

BLK(S) MISSING IN BIT MAPS
SALVAGE? no

SUMMARY INFORMATION BAD
SALVAGE? no

CLEAN FLAG NOT SET IN SUPERBLOCK
FIX? no

60922 files, 683350 used, 319143 free (11295 frags, 38481 blocks, 1.1% fragmentation)