2.6.22-rc1 killed my ext3 filesystem cleanly unmounted

[Martin Mokrejs]

Hi,
  I just tried the 2.6.22-r1 candidate to test whether some bug I have 
hit in the past still exists. I did use 2.6.20.6 so far. So, I have 
cleanly rebooted to use the new kernel, after the machine came up I 
tried to mess with the bug, and had to reboot again to play with kernel 
commandline parameters. Unfortunately, on the next reboot fsck was 
schedules on my filesystem after 38 clean mounts. :( And the problem 
started. The fsck found some unused inodes, but probably did not know 
where do they belong to, but it deleted them automagically. Finally, the 
fsck died because it cannot fine some '..' entry.

  Here is retyped what happened as recorded by my camera. ;)


/dev/hda3 has been mounted 38 times without being checked, check forced
HTREE directory inode 1163319 has an invalid root node.
HTREE INDEX CLEARED
Entry '..' in .../??? (5570587) has deleted/unused inode 5570561. 
CLEARED.
/dev/hda3: Entry '..' in .../??? (5570620) has deleted/unused inode 
5570561. CLEARED.
/dev/hda3: Entry '..' in .../??? (5570625) has deleted/unused inode
5570561. CLEARED.
/dev/hda3: Entry '..' in .../??? (5570567) has deleted/unused inode
5570561. CLEARED.
/dev/hda3: Entry '..' in .../??? (5570614) has deleted/unused inode
5570561. CLEARED.
/dev/hda3: Entry '..' in .../??? (5570603) has deleted/unused inode
5570561. CLEARED.
/dev/hda3: Entry '..' in .../??? (5586948) has deleted/unused inode
5570561. CLEARED.
/dev/hda3: Entry '..' in .../??? (5586957) has deleted/unused inode
5570561. CLEARED.
/dev/hda3: Entry '..' in .../??? (5701636) has deleted/unused inode
5570561. CLEARED.
Unconnected directory inode 5570567 (...)

/dev/hda3: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
                  (i.e., without -a or -p options)




  Turning off the power and booting back with 2.6.20.6 and obviously 
running same fsck gives me:

/dev/hda3 contains a file system with errors, check forced.
Missing '..' in direcotry inode 5570587.

/dev/hda3: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
                  (i.e., without -a or -p options)


  What do you recommend me now?

  I cannot say what is the fsck version, but I can tell you this is a 
Gentoo linux box in the ~x86 tree, so whatever is in the "unstable" 
branch. :(

  I do use ext2/ext3 windows driver from http://www.fs-driver.org/ to 
access the filesystem. Even now, when the filesystem should be marked as 
dirty I can access it from windows and see the files. Does the extfs.sys 
ignore the mark? ;) Anyway, since that time there is a directory 
'Recycled' at the top level of the filesystem. ;-)

  I do remember recently that possibly one of the system packages in 
Gentoo installed some kind of a hash into the filesystem, or hashing 
support, something like that. Sorry, I do not remember the details.
Am just think what could have made the fsck think there is something 
wrong.

  I think IO would like to restore the filesystem to the previous stage 
before running the fsck. How can I do it? No, I do not have a backup of 
the filesystem. :(

I subscribed to the email lists but please send me Cc: anyway. Many thanks.
Martin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/