Ext3 users - Jun 2001 - Inconsistent ext3fs after crash (2.2.19/0.0.7a)

Hi,
i am seeing something interesting since the upgrade to 2.2.19/0.0.7a - I am
experimenting with the am930 wireless driver and i am crashing on
module exit. Everytime i reboot afterwards the var fs on /dev/hda8
is inconsistent


[...]
Checking all file systems...
Parallelizing fsck version 1.21-WIP (01-Jun-2001)
/dev/hda7: recovering journal
/dev/hda7: clean, 39160/320640 files, 354596/640702 blocks
/dev/hda8: recovering journal
/dev/hda8: Clearing orphaned inode 96655 (uid=0, gid=0, mode=020600, size=0)
/dev/hda8: Already cleared block #0 (65025) found in orphaned inode 96655.
/dev/hda8 was not cleanly unmounted, check forced.
Deleted inode 96654 has zero dtime.  FIXED.
/dev/hda8: Inodes that were part of a corrupted orphan linked list found.

/dev/hda8: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
        (i.e., without -a or -p options)
/dev/hda9: recovering journal
/dev/hda9: clean, 11/128520 files, 24448/514048 blocks
/dev/hda10: recovering journal
/dev/hda10: clean, 229876/1921984 files, 3433405/3840472 blocks

fsck failed.  Please repair manually.

CONTROL-D will exit from this shell and continue system startup.

Give root password for maintenance
(or type Control-D for normal startup):
[...]

Checking the filesystem results in:

[...]
(none):~# fsck.ext3 -yf /dev/hda8
e2fsck 1.21-WIP, 01-Jun-2001 for EXT2 FS 0.5b, 95/08/09
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found.  Fix? yes

Inode 96655 was part of the orphaned inode list.  FIXED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Inode bitmap differences:  -96654 -96655
Fix? yes

Free inodes count wrong for group #6 (15784, counted=15786).
Fix? yes

Free inodes count wrong (120378, counted=120380).
Fix? yes


/dev/hda8: ***** FILE SYSTEM WAS MODIFIED *****
/dev/hda8: 8388/128768 files (0.8% non-contiguous), 92277/257032 blocks
[...]


This is 2.2.19 + ide/udma patches + ext3 patches on an ThinkPad T21

00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) (prog-if 80
[Master])
hda: IBM-DJSA-232, 30520MB w/1874kB Cache, CHS=4134/240/63, UDMA(33)

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Florian Lohoff wrote:
> 
> Hi,
> i am seeing something interesting since the upgrade to 2.2.19/0.0.7a - I am
> experimenting with the am930 wireless driver and i am crashing on
> module exit. Everytime i reboot afterwards the var fs on /dev/hda8
> is inconsistent
> 
Very interesting.  I have an *identical* report from a colleague
who is testing ext3-2.4-0.0.6 with e2fsprogs-1.20.  I've suggested
an e2fsprogs upgrade, but the 1.20 recovery problem is unlikely to
explain this.  And you're using 1.21.

	var: recovering journal
	/var: Clearing orphaned inode 36729 (uid=0, gid=0, mode=020600, size=0)
	/var: Already cleared block #0 (65025) found in orphaned inode 36729.
	/var was not cleanly umounted, check forced.
	/var
	Deleted inode 36728 has zero dtime.  FIXED.
	/var: Inodes that were part of a corrupted orphan linked list found.

	/var: UNEXPECTED INCONSYSTENCY; RUN fsck MANUALLY.

	When I run "fsck -yv" on /var, I get

	Pass 1: Checking inodes, blocks, and size
	Inodes that were part of a corrupted orphan linked list found. Fix? yes
	Inode 36729 was part of the  orphan linked list. FIXED.
	.....
	Pass 5: Checking group summary information
	Inode bitmap differences: -36728 -36729
	Fix? yes

	Free inodes count wrong for group #18 (2028, counted=2030).
	Fix? yes

	Free inodes count wrong (127821, counted=127823)
	Fix? yes

Files on /var tend to be opened in funny modes - lock files
with O_SYNC or whatever.  Might be violating ordering in some manner.

Could you please try a couple of things?

1: Use in-kernel recovery, not fsck recovery.  On RH systems
   you can do this by creating the file /fastboot (I think) or
   by adding `fastboot' to the kernel boot line.  Or you could
   simply boot with `init=/bin/sh' and do the mount by hand.

   Once the mount+recovery has completed, please unmount and run
   fsck by hand.  If it comes up clean then it may be an
   e2fsprogs problem.

2: It would be very interesting to find out what file is causing
   this.  Could you please run `ls -lRi /var > /tmp/foo' before
   you crash, then afterwards, look up the offending inode
   in /tmp/foo.  Once we know its filename, things may become
   clearer.

Thanks.

> Is there any chance you could make a copy of the
> partition available on a server so others can grab it?
> 	dd /dev/hda8 | gzip > some_server
> (Before running recovery!)
May I suggest

bzip2 -c -9 /dev/hda8 > some_server

(let's