xfstests failures in v3.13-rc7

xfstests failures in v3.13-rc7

[Verma, Vishal L]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

Hi,

I have been running xfstests with ext4 on a ramdisk (brd), and noticed a
few tests were failing with an inconsistent file system at the end of
the test.

The following fail for v3.13-rc7:
generic/013
generic/083
generic/269
generic/321 (this one is not inconsistent fs, see log)
generic/322

The output of xfstests for these failures is also attached.

It looks like generic/013 should be resolved by:
http://thread.gmane.org/gmane.comp.file-systems.ext4/42032
Are any of the others known failures, especially for brd?

Thanks,
	-Vishal


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: runtests.log --]
[-- Type: text/x-log; name="runtests.log", Size: 5075 bytes --]

===== Running generic/013 =====
FSTYP         -- ext4
PLATFORM      -- Linux/x86_64 dromcop5 3.13.0-rc7
MKFS_OPTIONS  -- /dev/ram1
MOUNT_OPTIONS -- -o acl,user_xattr /dev/ram1 /mnt/scratch

generic/013	 [failed, exit status 1] - output mismatch (see /home/vverma7/local-crsw/xfstests/results//generic/013.out.bad)
    --- tests/generic/013.out	2013-12-18 19:11:00.000000000 -0700
    +++ /home/vverma7/local-crsw/xfstests/results//generic/013.out.bad	2014-01-06 17:24:23.181444267 -0700
    @@ -4,11 +4,4 @@
     -----------------------------------------------
     fsstress.1 : -r
     -----------------------------------------------
    -
    ------------------------------------------------
    -fsstress.2 : -p 20 -r
    ------------------------------------------------
     ...
     (Run 'diff -u tests/generic/013.out /home/vverma7/local-crsw/xfstests/results//generic/013.out.bad' to see the entire diff)
_check_generic_filesystem: filesystem on /dev/ram0 is inconsistent (see /home/vverma7/local-crsw/xfstests/results//generic/013.full)
Ran: generic/013
Failures: generic/013
Failed 1 of 1 tests
===== Done with 1 =====


===== Running generic/083 =====
FSTYP         -- ext4
PLATFORM      -- Linux/x86_64 dromcop5 3.13.0-rc7
MKFS_OPTIONS  -- /dev/ram1
MOUNT_OPTIONS -- -o acl,user_xattr /dev/ram1 /mnt/scratch

generic/083	 [failed, exit status 1] - output mismatch (see /home/vverma7/local-crsw/xfstests/results//generic/083.out.bad)
    --- tests/generic/083.out	2013-12-18 19:11:00.000000000 -0700
    +++ /home/vverma7/local-crsw/xfstests/results//generic/083.out.bad	2014-01-06 17:26:02.594442677 -0700
    @@ -1,4 +1,4 @@
     QA output created by 083
     *** test out-of-space handling for random write operations
    -*** done
    +_check_generic_filesystem: filesystem on /dev/ram1 is inconsistent (see /home/vverma7/local-crsw/xfstests/results//generic/083.full)
     *** unmount
     ...
     (Run 'diff -u tests/generic/083.out /home/vverma7/local-crsw/xfstests/results//generic/083.out.bad' to see the entire diff)
Ran: generic/083
Failures: generic/083
Failed 1 of 1 tests
===== Done with 1 =====


===== Running generic/269 =====
FSTYP         -- ext4
PLATFORM      -- Linux/x86_64 dromcop5 3.13.0-rc7
MKFS_OPTIONS  -- /dev/ram1
MOUNT_OPTIONS -- -o acl,user_xattr /dev/ram1 /mnt/scratch

generic/269	 [failed, exit status 1] - output mismatch (see /home/vverma7/local-crsw/xfstests/results//generic/269.out.bad)
    --- tests/generic/269.out	2013-12-18 19:11:00.000000000 -0700
    +++ /home/vverma7/local-crsw/xfstests/results//generic/269.out.bad	2014-01-06 17:38:07.426431091 -0700
    @@ -3,3 +3,4 @@
     Run fsstress
     
     Run dd writers in parallel
    +_check_generic_filesystem: filesystem on /dev/ram1 is inconsistent (see /home/vverma7/local-crsw/xfstests/results//generic/269.full)
     ...
     (Run 'diff -u tests/generic/269.out /home/vverma7/local-crsw/xfstests/results//generic/269.out.bad' to see the entire diff)
Ran: generic/269
Failures: generic/269
Failed 1 of 1 tests
===== Done with 1 =====


===== Running generic/321 =====
FSTYP         -- ext4
PLATFORM      -- Linux/x86_64 dromcop5 3.13.0-rc7
MKFS_OPTIONS  -- /dev/ram1
MOUNT_OPTIONS -- -o acl,user_xattr /dev/ram1 /mnt/scratch

generic/321	 [failed, exit status 1] - output mismatch (see /home/vverma7/local-crsw/xfstests/results//generic/321.out.bad)
    --- tests/generic/321.out	2013-12-18 19:11:00.000000000 -0700
    +++ /home/vverma7/local-crsw/xfstests/results//generic/321.out.bad	2014-01-06 17:44:38.400424842 -0700
    @@ -1,9 +1,8 @@
     QA output created by 321
     fsync new directory
     drwxr-xr-x bar
    +drwx------ lost+found
     rename fsync test
     drwxr-xr-x bar
     -rw-r--r-- foo
     ...
     (Run 'diff -u tests/generic/321.out /home/vverma7/local-crsw/xfstests/results//generic/321.out.bad' to see the entire diff)
Ran: generic/321
Failures: generic/321
Failed 1 of 1 tests
===== Done with 1 =====


===== Running generic/322 =====
FSTYP         -- ext4
PLATFORM      -- Linux/x86_64 dromcop5 3.13.0-rc7
MKFS_OPTIONS  -- /dev/ram1
MOUNT_OPTIONS -- -o acl,user_xattr /dev/ram1 /mnt/scratch

generic/322	 [failed, exit status 1] - output mismatch (see /home/vverma7/local-crsw/xfstests/results//generic/322.out.bad)
    --- tests/generic/322.out	2013-12-18 19:11:00.000000000 -0700
    +++ /home/vverma7/local-crsw/xfstests/results//generic/322.out.bad	2014-01-06 17:44:50.509424648 -0700
    @@ -5,3 +5,4 @@
     fsync rename test
     d34ff04c17ef7068d78d0c4be49cfe57  /mnt/scratch/bar
     d34ff04c17ef7068d78d0c4be49cfe57  /mnt/scratch/bar
    +_check_generic_filesystem: filesystem on /dev/mapper/flakey-test is inconsistent (see /home/vverma7/local-crsw/xfstests/results//generic/322.full)
     ...
     (Run 'diff -u tests/generic/322.out /home/vverma7/local-crsw/xfstests/results//generic/322.out.bad' to see the entire diff)
Ran: generic/322
Failures: generic/322
Failed 1 of 1 tests
===== Done with 1 =====

Re: xfstests failures in v3.13-rc7

[Jan Kara]

On Tue 07-01-14 02:57:13, Verma, Vishal L wrote:
> Hi,
> 
> I have been running xfstests with ext4 on a ramdisk (brd), and noticed a
> few tests were failing with an inconsistent file system at the end of
> the test.
> 
> The following fail for v3.13-rc7:
> generic/013
> generic/083
> generic/269
> generic/321 (this one is not inconsistent fs, see log)
> generic/322
> 
> The output of xfstests for these failures is also attached.
> 
> It looks like generic/013 should be resolved by:
> http://thread.gmane.org/gmane.comp.file-systems.ext4/42032
> Are any of the others known failures, especially for brd?
  Are you using any special mkfs options? Because the referenced patch
should fix only a problem if you are using bigalloc feature...

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

Re: xfstests failures in v3.13-rc7

[jon ernst]

Vishal,

I am ext4 newbie. Though I could share my experience about test 013 failure.
Make sure you have latest (or 1.42.9) e2fsck installed on your system.

Notice that v1.42.8 will cause 013 fail due to this:
http://comments.gmane.org/gmane.comp.file-systems.ext4/39980

To confirm my guess, you can check your xfstest full log to see if
e2fsck fail or not.


Just my idea. Could be wrong. Please correct me.

Best,
Jon

On Tue, Jan 7, 2014 at 2:57 AM, Verma, Vishal L
<vishal.l.verma@intel.com> wrote:
> Hi,
>
> I have been running xfstests with ext4 on a ramdisk (brd), and noticed a
> few tests were failing with an inconsistent file system at the end of
> the test.
>
> The following fail for v3.13-rc7:
> generic/013
> generic/083
> generic/269
> generic/321 (this one is not inconsistent fs, see log)
> generic/322
>
> The output of xfstests for these failures is also attached.
>
> It looks like generic/013 should be resolved by:
> http://thread.gmane.org/gmane.comp.file-systems.ext4/42032
> Are any of the others known failures, especially for brd?
>
> Thanks,
>         -Vishal
>

Re: xfstests failures in v3.13-rc7

[Matthew Wilcox]

On Wed, Jan 08, 2014 at 04:56:19AM +0000, jon ernst wrote:
> I am ext4 newbie. Though I could share my experience about test 013 failure.
> Make sure you have latest (or 1.42.9) e2fsck installed on your system.
> 
> Notice that v1.42.8 will cause 013 fail due to this:
> http://comments.gmane.org/gmane.comp.file-systems.ext4/39980

Thank you, Jon!  I installed 1.42.9 and 013 ran successfully.  Now that
lazy Debian maintainer needs to package it!

(Seriously, 1.42.9-2 is already in unstable; it just needs another 2
days to migrate to testing.  Good job, Ted :-)

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: xfstests failures in v3.13-rc7

[Lukáš Czerner]

On Tue, 7 Jan 2014, Verma, Vishal L wrote:

> Date: Tue, 7 Jan 2014 02:57:13 +0000
> From: "Verma, Vishal L" <vishal.l.verma@intel.com>
> To: "linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
> Cc: "matthew@wil.cx" <matthew@wil.cx>
> Subject: xfstests failures in v3.13-rc7
> 
> Hi,
> 
> I have been running xfstests with ext4 on a ramdisk (brd), and noticed a
> few tests were failing with an inconsistent file system at the end of
> the test.
> 
> The following fail for v3.13-rc7:
> generic/013
> generic/083
> generic/269
> generic/321 (this one is not inconsistent fs, see log)
> generic/322

Hi,

Unfortunately you have not provided *.full logs, but I believe that
at least 013, 083 and 269 failures are caused by bug in e2fsprogs
which was fixed with:

085757fcc22a86168ee6793dfad9a95d88fb09db e2fsck: don't report uninit
extents past EOF invalid

which is present in the lates e2fsprogs release 1.42.9.

Please retest with that.

Thanks!
-Lukas

> 
> The output of xfstests for these failures is also attached.
> 
> It looks like generic/013 should be resolved by:
> http://thread.gmane.org/gmane.comp.file-systems.ext4/42032
> Are any of the others known failures, especially for brd?
> 
> Thanks,
> 	-Vishal
> 
> 

Re: xfstests failures in v3.13-rc7

[Verma, Vishal L]

On Wed, 2014-01-08 at 04:56 +0000, jon ernst wrote:
> Vishal,
> 
> I am ext4 newbie. Though I could share my experience about test 013 failure.
> Make sure you have latest (or 1.42.9) e2fsck installed on your system.
> 
> Notice that v1.42.8 will cause 013 fail due to this:
> http://comments.gmane.org/gmane.comp.file-systems.ext4/39980
> 
Thanks, Jon! That did solve the tests failing with inconsistent fs.

As an aside, when I installed e2fsprogs using simply 'make install', it
replaced /sbin/blkid with it's own version (1.0.0), down from what I had
(2.x). Reinstalling the util-linux-ng package brings me back up...
(I had to modify the check script in xfstests to use the -p option in
blkid to actually read superblock since ramdisks don't seem to make it
into /etc/blkid/blkid.tab, and this wasn't there in blkid v1.0.0).

I quickly searched for a bit of history on the topic, and sounds like I
should be using --disable-libblkid for configure. Tried that, and got
some errors, the same as seen here:
http://patchwork.ozlabs.org/patch/36491/

Any suggestions?

Thanks,
	-Vishal

Re: xfstests failures in v3.13-rc7

[Theodore Ts'o]

On Thu, Jan 09, 2014 at 02:09:52AM +0000, Verma, Vishal L wrote:
> As an aside, when I installed e2fsprogs using simply 'make install', it
> replaced /sbin/blkid with it's own version (1.0.0), down from what I had
> (2.x). Reinstalling the util-linux-ng package brings me back up...
> (I had to modify the check script in xfstests to use the -p option in
> blkid to actually read superblock since ramdisks don't seem to make it
> into /etc/blkid/blkid.tab, and this wasn't there in blkid v1.0.0).
> 
> I quickly searched for a bit of history on the topic, and sounds like I
> should be using --disable-libblkid for configure. Tried that, and got
> some errors, the same as seen here:
> http://patchwork.ozlabs.org/patch/36491/

Did you do a full "make distclean" after you reran the configure
script?  This was caused by a left over header file, if memory serves
correctly.

If you used a separate build directory (i.e., "mkdir build ; cd build
; ../configure --enable-...") then just rm -rf the build directory and
then start from scratch.  If you used git, you can do "git clean
-xdq".  If neither of these apply, you may need to delete the full
source tree and then unpack the source tarfile again.

I'm open to patches to make this the transition between one set of
configure options to another more smooth, but given that I tend to
just do things like have multiple build directories, for things like
"build-coverity", "build-quota", "build-dietlibc", etc., it's not high
on my priority list to figure out why someone who fails to run "make
distclean", or deletes the full build tree, before running configure
with a different set of options, is losing.

					- Ted

Re: xfstests failures in v3.13-rc7

[Verma, Vishal L]

On Sat, 2014-01-11 at 16:58 -0500, Theodore Ts'o wrote:
> On Thu, Jan 09, 2014 at 02:09:52AM +0000, Verma, Vishal L wrote:
> > As an aside, when I installed e2fsprogs using simply 'make install', it
> > replaced /sbin/blkid with it's own version (1.0.0), down from what I had
> > (2.x). Reinstalling the util-linux-ng package brings me back up...
> > (I had to modify the check script in xfstests to use the -p option in
> > blkid to actually read superblock since ramdisks don't seem to make it
> > into /etc/blkid/blkid.tab, and this wasn't there in blkid v1.0.0).
> > 
> > I quickly searched for a bit of history on the topic, and sounds like I
> > should be using --disable-libblkid for configure. Tried that, and got
> > some errors, the same as seen here:
> > http://patchwork.ozlabs.org/patch/36491/
> 
> Did you do a full "make distclean" after you reran the configure
> script?  This was caused by a left over header file, if memory serves
> correctly.
> 
> If you used a separate build directory (i.e., "mkdir build ; cd build
> ; ../configure --enable-...") then just rm -rf the build directory and
> then start from scratch.  If you used git, you can do "git clean
> -xdq".  If neither of these apply, you may need to delete the full
> source tree and then unpack the source tarfile again.
> 
Thanks! A git clean did solve the problem.

> I'm open to patches to make this the transition between one set of
> configure options to another more smooth, but given that I tend to
> just do things like have multiple build directories, for things like
> "build-coverity", "build-quota", "build-dietlibc", etc., it's not high
> on my priority list to figure out why someone who fails to run "make
> distclean", or deletes the full build tree, before running configure
> with a different set of options, is losing.
> 
> 					- Ted