Date: Tue, 23 Nov 1999 15:32:11 -0600 (CST) From: "Kevin J. Meehan" <kjm@arc.umn.edu> To: FreeBSD-gnats-submit@freebsd.org Subject: kern/15065: fsck can't fix "huge" zero length files Message-ID: <199911232132.PAA42114@delenn.arc.umn.edu>
index | next in thread | raw e-mail
>Number: 15065 >Category: kern >Synopsis: fsck can't fix "huge" zero length files >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Nov 23 13:40:00 PST 1999 >Closed-Date: >Last-Modified: >Originator: Kevin J. Meehan >Release: FreeBSD 3.3-STABLE i386 >Organization: Network Computing Services, Inc. >Environment: We have FreeBSD PC with a RAID subsystem that has a pair of CMD TECH CRD-5640 scsi controllers meant to back each other up should one fail. Unfortunately they had the first version of the firmware which was prone to double faulting-a situation that would mean both would hang and a power cycle was the only thing that would unlock the two controllers. >Description: After a particularly bad week with 3 "double faults", one of the 5 filesystems on the RAID subsystem had some odd files the system pushed to the lost+found directory: c--Sr-S--T 1 cheng si 147, 0x004f00ac Dec 31 1969 #1261947 lrwxr-S--- 1 demlow ncs 4638043271730144200 Dec 31 1969 #2484071@ -> s--x--S--- 1 root wheel 4631321269953217064 Dec 31 1969 #2484095= The size returned by dump was a large negative number and thus broke Amanda. An umount and fsck of the filesystem would not fix the above. >How-To-Repeat: Difficult-get a hold of a bum controller and have it munge your filesystem. (Not recommended!) >Fix: We finally needed to use fsdb to remove the offending inodes. Note that while the link and file show huge sizes, their block counts are 0: fsdb (inum: 2)> inode 2484071 current inode: symlink I=2484071 MODE=122740 SIZE=4638043271730144200 MTIME=Dec 31 18:00:00 1969 [1 nsec] CTIME=Oct 20 14:23:00 1999 [0 nsec] ATIME=Dec 31 18:00:00 1969 [0 nsec] OWNER=demlow GRP=ncs LINKCNT=1 FLAGS=0 BLKCNT=0 GEN=56ef2b95 fsdb (inum: 2484071)> inode 2484095 current inode: socket I=2484095 MODE=142100 SIZE=4631321269953217064 MTIME=Dec 31 18:00:00 1969 [1 nsec] CTIME=Apr 9 17:05:23 1999 [0 nsec] ATIME=Dec 31 18:00:00 1969 [0 nsec] OWNER=root GRP=wheel LINKCNT=1 FLAGS=0 BLKCNT=0 GEN=25cd617b fsdb (inum: 2484095)> inode 1261947 current inode: character special (147,5177516)I=1261947 MODE=27040 SIZE=4639318980096568328 MTIME=Dec 31 18:00:00 1969 [1 nsec] CTIME=Sep 9 13:30:59 1999 [0 nsec] ATIME=Dec 31 18:00:00 1969 [0 nsec] OWNER=cheng GRP=si LINKCNT=1 FLAGS=0 BLKCNT=0 GEN=1552126f # /sbin/fsck /home1 ** /dev/rda2s1e ** Last Mounted on /mnt ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames UNALLOCATED I=2484071 OWNER=root MODE=0 SIZE=0 MTIME=Dec 31 18:00 1969 NAME=/lost+found/#2484071 REMOVE? [yn] y UNALLOCATED I=2484095 OWNER=root MODE=0 SIZE=0 MTIME=Dec 31 18:00 1969 NAME=/lost+found/#2484095 REMOVE? [yn] y UNALLOCATED I=1261947 OWNER=root MODE=0 SIZE=0 MTIME=Dec 31 18:00 1969 NAME=/lost+found/#1261947 REMOVE? [yn] y ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? [yn] y SUMMARY INFORMATION BAD SALVAGE? [yn] y BLK(S) MISSING IN BIT MAPS SALVAGE? [yn] y 56770 files, 3812612 used, 6350567 free (6759 frags, 792976 blocks, 0.1% fragmentation) ***** FILE SYSTEM MARKED CLEAN ***** ***** FILE SYSTEM WAS MODIFIED ***** # /sbin/fsck /home1 ** /dev/rda2s1e ** Last Mounted on /mnt ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 56770 files, 3812612 used, 6350567 free (6759 frags, 792976 blocks, 0.1% fragmentation) We finally upgraded the firmware on the controllers from version 1 to 9 on Nov 3rd and have been trouble free up to this point-but it was usually about a month in between lock ups. We were torn as to whether or not this should be reported. For one thing we had bum hardware. That is not FreeBSD's fault. On the other hand, the sizes reported are obviously rediculously huge and the block counts are zero. In the end we decided to let you know and let you decide whether fsck should fix something like this automatically, or flag it as something that needs to be manually removed, or not. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the messagehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911232132.PAA42114>
