Messages in this thread | | | Date | Sun, 29 Jun 2008 12:31:23 +0100 (BST) | From | Hugh Dickins <> | Subject | Re: 2.6.26-rc7-mmotd-0626 ext3-validate-directory-entry-data-before-use.patch |
| |
On Sun, 29 Jun 2008, Valdis.Kletnieks@vt.edu wrote: > I'm seeing some ext3 errors, and I'm suspecting the patch > ext3-validate-directory-entry-data-before-use.patch is causing them > (since it seems to be the only thing in rc7-mmotd at the moment that > touches make_indexed_dir, and -rc5-mm3 works OK). > > Jun 28 21:50:29 turing-police kernel: [ 240.784199] EXT3-fs error (device dm-7): make_indexed_dir: bad entry in directory #9894: directory entry across blocks - offset=0, inode=10144, rec_len=32, name_len=22 > Jun 28 21:50:29 turing-police kernel: [ 240.784214] Aborting journal on device dm-7. > Jun 28 21:50:29 turing-police kernel: [ 240.784597] Remounting filesystem read-only > Jun 28 21:50:29 turing-police kernel: [ 240.785616] EXT3-fs error (device dm-7): do_split: bad entry in directory #9894: rec_len is smaller than minimal - offset=0, inode=2553887680, rec_len=0, name_len=0 > Jun 28 21:50:29 turing-police kernel: [ 240.785616] EXT3-fs error (device dm-7) in ext3_reserve_inode_write: Journal has aborted > Jun 28 21:50:29 turing-police kernel: [ 241.027111] __journal_remove_journal_head: freeing b_committed_data > > Jun 28 23:09:54 turing-police kernel: [ 5026.698415] EXT3-fs error (device dm-2): make_indexed_dir: bad entry in directory #369136: directory entry across blocks - offset=0, inode=369138, rec_len=20, name_len=11 > Jun 28 23:09:54 turing-police kernel: [ 5026.698415] Aborting journal on device dm-2. > Jun 28 23:09:54 turing-police kernel: [ 5026.698519] Remounting filesystem read-only > Jun 28 23:09:54 turing-police kernel: [ 5026.702730] EXT3-fs error (device dm-2): do_split: bad entry in directory #369136: directory entry across blocks - offset=0, inode=106647, rec_len=12, name_len=1 > Jun 28 23:09:54 turing-police kernel: [ 5026.702730] EXT3-fs error (device dm-2) in ext3_reserve_inode_write: Journal has aborted > > I believe I have a reasonably good replicator for the error on dm-7, that's my /usr/share > and trying to 'rpm -Fvh' one specific RPM has caused it twice (in two tries). > > The file systems appear to be OK (or at least the fsck.ext3 in Fedora's > e2fsprogs-1.41-0.WIP.0617.1.fc10.x86_64 says both file systems are in fact OK). > > Any comments/suggestions? Any testing/debugging you'd like, > or should I just revert it and move on?
Thanks for the warning, yes, me too. All I have to do is boot up and cp -al a kernel source tree: that starts generating lots of these errors, I Ctrl-C out, unmount the filesystem, then fsck -f has lots of work to do.
So not only does the patch find directory entries invalid which have given no trouble in the past, it handles them in such a way as to leave the filesystem messed up where it wasn't before.
And build even gives a compile warning, haven't looked if it's significant: fs/ext3/namei.c: In function ‘make_indexed_dir’: fs/ext3/namei.c:1435: warning: comparison of distinct pointer types lacks a cast
I think I don't want to investigate this one! I've hurriedly reverted
ext3-validate-directory-entry-data-before-use-checkpatch-fixes.patch ext3-validate-directory-entry-data-before-use.patch
, checked that cp -al on the kernel source tree now gives me no errors, checked that fsck -f is happy with the resultant filesystem, now moving on.
Hugh | |