Subject: kern/21060: ufs looks like it's mighty hosed
To: None <gnats-bugs@gnats.netbsd.org>
From: Tom Spindler <dogcow@beefcake.babymeat.com>
List: netbsd-bugs
Date: 04/07/2003 02:16:52
>Number: 21060
>Category: kern
>Synopsis: ufs looks like it's mighty hosed
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon Apr 07 16:59:01 PDT 2003
>Closed-Date:
>Last-Modified:
>Originator: Tom Spindler
>Release: NetBSD 1.6Q
>Organization:
>Environment:
System: NetBSD beefcake.babymeat.com 1.6Q NetBSD 1.6Q (BEEFCAKE) #31: Mon Apr 7 01:28:01 PDT 2003 dogcow@beefcake.babymeat.com:/usr/src/sys/arch/i386/compile/BEEFCAKE i386
Architecture: i386
Machine: i386
>Description:
With the warning from fvdl, I rebooted with the kernel from today, and
`fsck -yf /home`ed; fsck decided that an entire directory of files were
unlinked, and that it should relink them. Now I get this fun behavior:
$ ls -1 | wc -w
5694
$ file ./\#34111
./#34111: JPEG image data, JFIF standard 1.02, resolution (DPI), 72 x 72
$ find . -name \*3\* -print | xargs file | grep 34111
./#34111: executable,
$ find . -name \?3\* -print | xargs file | grep 34111
./#34111: JPEG image data, JFIF standard 1.01, aspect ratio, "File written with CompuPic(R) -", 1 x 1
$ find . -name \?34\* -print | xargs file | grep 34111
./#34111: JPEG image data, JFIF standard 1.02, resolution (DPI), 72 x 72
$ find . -name \*3\* -print | xargs -n 500 file | grep 34111
./#34111: JPEG image data, JFIF standard 1.00, aspect ratio, "LEAD Technologies Inc. V1.01", 150 x 150
$ find . -name \*3\* -print | xargs -n 350 file | grep 34111
./#34111: JPEG image data, JFIF standard 1.02, resolution (DPI), 72 x 72
$ find . -name \*3\* -print | xargs -n 400 file | grep 34111
./#34111: JPEG image data, JFIF standard 1.01, aspect ratio, 0 x 0
It's always repeatable; the order in which the find(1)'s are done
does not matter, nor does the shell. This seems Bad.
>How-To-Repeat:
boot kernel with new ufs code; fsck with the new fsck; large amounts
of directory data seem to get hosed depending on how many filenames
it's passed in one fell swoop.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: