Re: e2fsprogs w/64-bit patches: make check gets one failure

[Andreas Dilger <adilger@sun.com>]

On Mar 12, 2009  10:11 -0400, Nick Dokos wrote:
> Andreas Dilger <adilger@sun.com> wrote:
> > On Mar 11, 2009  14:53 -0400, Nick Dokos wrote:
> > > I followed the workflow that Ted described in the following message:
> > > 
> > >    http://marc.info/?l=linux-ext4&m=123367642710241&w=2
> > > 
> > > with the patch series from git://github.com/tytso/e2fsprogs-64bit.git
> > > 
> > > With all the patches in the series file applied, make check gives
> > > me the following error:
> > > 
> > > ...
> > > f_h_reindex: reindex HTREE Directory with different hash seed: failed
> > > ...
> > > 100 tests succeeded	1 tests failed
> > > make[1]: *** [check] Error 1
> > > make[1]: Leaving directory `/home/nick/src/e2fsprogs/standard/build/tests'
> > > make: *** [check-recursive] Error 1
> > 
> > Including the content of the tests/f_h_reindex.failed file might make
> > the problem obvious.  Possibly it is just some change in the output
> > format that is causing expect to fail.
> > 
> 
> Here's the f_h_reindex.failed file:
> 
> --- ../../tests/f_h_reindex/expect.1	2009-03-09 17:14:20.000000000 +0000
> +++ f_h_reindex.1.log	2009-03-12 14:18:05.000000000 +0000
> @@ -954,5 +954,5 @@
>  Pass 5: Checking group summary information
>  
>  test_filesys: ***** FILE SYSTEM WAS MODIFIED *****
> -test_filesys: 30514/32000 files (0.0% non-contiguous), 5669/8000 blocks
> +test_filesys: 30514/32000 files (0.0% non-contiguous), 5560/8000 blocks
>  Exit status is 1
> --- ../../tests/f_h_reindex/expect.2	2009-03-09 17:14:20.000000000 +0000
> +++ f_h_reindex.2.log	2009-03-12 14:18:05.000000000 +0000
> @@ -1,7 +1,10823 @@
>  Pass 1: Checking inodes, blocks, and sizes
> +Inode 24001, i_size is 596992, should be 485376.  Fix? yes

This looks like it is causing an inode to be truncated.

>  Pass 2: Checking directory structure
> +Problem in HTREE directory inode 24001 (/test2): bad block number 578.
> +Clear HTree index? yes

Supporting evidence that this is a directory being truncated.

>  Pass 3: Checking directory connectivity
> +Pass 3A: Optimizing directories
>  Pass 4: Checking reference counts
> +Unattached zero-length inode 12.  Clear? yes
> +
> +Unattached zero-length inode 13.  Clear? yes

These are all of the inodes that were lost from the truncated directory.

This seems like a non-trivial failure and needs to be investigated.
Posting the offending patch (assuming you can pass "make check" before
the patch, and fail afterward) would get more eyes on the subject.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.