ext2 issues with xfstests 113

ext2 issues with xfstests 113

[Christoph Hellwig]

fsck from util-linux-ng 2.17
e2fsck 1.41.11 (14-Mar-2010)
Pass 1: Checking inodes, blocks, and sizes
Inode 22, i_blocks is 20512, should be 16512.  Fix? no

Inode 31, i_blocks is 20512, should be 16512.  Fix? no

Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -(8090--8191) -(43829--44328) -(51784--52181)
Fix? no

Re: ext2 issues with xfstests 113

[Jan Kara]

On Mon 31-05-10 11:46:25, Christoph Hellwig wrote:
> fsck from util-linux-ng 2.17
> e2fsck 1.41.11 (14-Mar-2010)
> Pass 1: Checking inodes, blocks, and sizes
> Inode 22, i_blocks is 20512, should be 16512.  Fix? no
> 
> Inode 31, i_blocks is 20512, should be 16512.  Fix? no
> 
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
> Block bitmap differences:  -(8090--8191) -(43829--44328) -(51784--52181)
> Fix? no
  Are you able to reproduce this? Because for me ext2 runs went just
fine...

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

Re: ext2 issues with xfstests 113

[Christoph Hellwig]

On Mon, May 31, 2010 at 07:57:47PM +0200, Jan Kara wrote:
>   Are you able to reproduce this? Because for me ext2 runs went just
> fine...

I've done a couple of runs both on current mainline and the 2.6.34
based XFS tree and they all show this problem.

Re: ext2 issues with xfstests 113

[Jan Kara]

On Mon 31-05-10 20:01:01, Christoph Hellwig wrote:
> On Mon, May 31, 2010 at 07:57:47PM +0200, Jan Kara wrote:
> >   Are you able to reproduce this? Because for me ext2 runs went just
> > fine...
> 
> I've done a couple of runs both on current mainline and the 2.6.34
> based XFS tree and they all show this problem.
  Hmm, interesting because I've run test 113 again with a kernel somewhere
between 2.6.34 and 2.6.35-rc1 and the filesystem is clean. So probably you
are able to hit some kind of race I'm not able to. Could you check whether
the corruption is caused by the O_DIRECT run or some other one?
  Also could you get "e2image -r" of the filesystem, bzip2 it and put it
somewhere for download?

									Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

Re: ext2 issues with xfstests 113

[Jan Kara]

On Tue 01-06-10 11:03:37, Christoph Hellwig wrote:
> On Mon, May 31, 2010 at 11:31:01PM +0200, Jan Kara wrote:
> >   Hmm, interesting because I've run test 113 again with a kernel somewhere
> > between 2.6.34 and 2.6.35-rc1 and the filesystem is clean. So probably you
> > are able to hit some kind of race I'm not able to. Could you check whether
> > the corruption is caused by the O_DIRECT run or some other one?
> 
> 113 is an AIO test, so it must be using O_DIRECT.
  Why? Looking at aio-stress source and 113 script, two of aio-stress runs
use buffered IO and only the last one uses O_DIRECT...

> >   Also could you get "e2image -r" of the filesystem, bzip2 it and put it
> > somewhere for download?
> 
> I've jyst attached it as the compressed version is small enough (88k).
  Thanks, I'll have a look whether I can guess something.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

Re: ext2 issues with xfstests 113

[Jan Kara]

On Tue 01-06-10 11:03:37, Christoph Hellwig wrote:
> On Mon, May 31, 2010 at 11:31:01PM +0200, Jan Kara wrote:
> >   Hmm, interesting because I've run test 113 again with a kernel somewhere
> > between 2.6.34 and 2.6.35-rc1 and the filesystem is clean. So probably you
> > are able to hit some kind of race I'm not able to. Could you check whether
> > the corruption is caused by the O_DIRECT run or some other one?
> 
> 113 is an AIO test, so it must be using O_DIRECT.
  Now I see that the third run of aio-stress failed so yes, it's using
O_DIRECT.

> >   Also could you get "e2image -r" of the filesystem, bzip2 it and put it
> > somewhere for download?
> 
> I've jyst attached it as the compressed version is small enough (88k).
  I've looked at the image and for both corrupted inodes it looks as if
we didn't write double-indirect block. The blocks which should be
presumably referenced from it are properly allocated so it couldn't be just
truncated or so. I've tried to reproduce the problem on another machine but
failed... Is there anything special in your setup? Also are there any
messages in the kernel log?

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR