Subject: fsck_lfs not actually fixing anything. :-(
To: None <port-alpha@netbsd.org>
From: Paul Mather <paul@gromit.dlib.vt.edu>
List: port-alpha
Date: 11/14/2002 11:29:59
Yesterday, I left my NetBSD/alpha 1.6K-current system doing a
/usr/src/build.sh.  This morning I woke up to find it doing a repeated
panic -> reboot -> fsck -> mount -> panic -> reboot cycle.  (That's
not a nice thing to wake up to find.) :-(

When I stopped it and booted single-user, I discovered that one of my
file systems paniced the machine when I tried to mount it.  It is a
LFS file system.  (I recently switched over my /usr/obj file system
from FFS to LFS to try it out.)  The panic message I get is this:

     panic: getblk: block size invariant failed

I was puzzled because all the file systems completed their fsck.  To
cut a long story short, the LFS file system completes fsck, but
apparently all the "fixes" it reports making are never actually
applied to the file system.  When I run fsck twice on the LFS file
system, it reports the same faults and fixes on the second fsck as it
did on the first.

Has anyone else encountered this problem?

I plan on newfs'ing the file system back to FFS, though I can hang on
a little while if anyone wants me to provide any additional info.

FYI, attached to the end is the output of fsck_lfs run twice in a row
on the damaged file system.

Cheers,

Paul.

e-mail: paul@gromit.dlib.vt.edu

"Without music to decorate it, time is just a bunch of boring production
 deadlines or dates by which bills must be paid."
        --- Frank Vincent Zappa

>>>>>
# fsck_lfs -d -y /dev/rsd1c
** /dev/rsd1c
sb0 sn=12711, sb1 sn=12711
dev_bsize = 512
lfs_bsize = 16384
lfs_fsize = 2048
lfs_frag  = 8
INOPB(fs) = 16
INOPF(fs) = 4
maxino    = 26208
** Last Mounted on /usr/obj
** Phase 0 - Check Segment Summaries and Inode Free List
** Phase 1 - Check Blocks and Sizes
creating inode address table...
counting dirs...
counting blocks...
PARTIALLY TRUNCATED INODE I=10683
SALVAGE? yes

2231 DUP I=11456
** Phase 2 - Check Pathnames
DUP/BAD  I=11456  OWNER=root MODE=100644
SIZE=54761 MTIME=Nov 14 06:37 2002 
FILE=/lib/libcrypto/evp_err.ln

REMOVE? yes

UNALLOCATED  I=11488 
INO is NULL

REMOVE? yes

UNALLOCATED  I=10338 
INO is NULL

REMOVE? yes

** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Segment Block Accounting
segment 20 claims 78720 bytes but has 64384 (high by 14336)

fix? yes

segment 984 claims 81920 bytes but has 176128 (low by 94208)

fix? yes

25581 files, 254780 used, 0 free 
The following duplicate blocks remain: 2231,

UPDATE STANDARD SUPERBLOCKS? yes

cache missed 10452 of 319470 (3%)

***** FILE SYSTEM WAS MODIFIED *****
# fsck_lfs -d -y /dev/rsd1c
** /dev/rsd1c
sb0 sn=12711, sb1 sn=12711
dev_bsize = 512
lfs_bsize = 16384
lfs_fsize = 2048
lfs_frag  = 8
INOPB(fs) = 16
INOPF(fs) = 4
maxino    = 26208
** Last Mounted on /usr/obj
** Phase 0 - Check Segment Summaries and Inode Free List
** Phase 1 - Check Blocks and Sizes
creating inode address table...
counting dirs...
counting blocks...
PARTIALLY TRUNCATED INODE I=10683
SALVAGE? yes

2231 DUP I=11456
** Phase 2 - Check Pathnames
DUP/BAD  I=11456  OWNER=root MODE=100644
SIZE=54761 MTIME=Nov 14 06:37 2002 
FILE=/lib/libcrypto/evp_err.ln

REMOVE? yes

UNALLOCATED  I=11488 
INO is NULL

REMOVE? yes

UNALLOCATED  I=10338 
INO is NULL

REMOVE? yes

** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Segment Block Accounting
segment 20 claims 78720 bytes but has 64384 (high by 14336)

fix? yes

segment 984 claims 81920 bytes but has 176128 (low by 94208)

fix? yes

25581 files, 254780 used, 0 free 
The following duplicate blocks remain: 2231,

UPDATE STANDARD SUPERBLOCKS? yes

cache missed 10452 of 319470 (3%)

***** FILE SYSTEM WAS MODIFIED *****
# 
<<<<<