[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Inconsistent ext3fs after crash (2.2.19/0.0.7a)



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.





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]