[<prev] [next>] [day] [month] [year] [list]
Message-id: <20090312203645.GI3199@webber.adilger.int>
Date: Thu, 12 Mar 2009 14:36:45 -0600
From: Andreas Dilger <adilger@....com>
To: Nick Dokos <nicholas.dokos@...com>
Cc: linux-ext4@...r.kernel.org
Subject: Re: e2fsprogs w/64-bit patches: make check gets one failure
On Mar 12, 2009 10:11 -0400, Nick Dokos wrote:
> Andreas Dilger <adilger@....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.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists