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
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 <[email protected]>
SUSE Labs, CR
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
<[email protected]> 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
>
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."
On Tue, 7 Jan 2014, Verma, Vishal L wrote:
> Date: Tue, 7 Jan 2014 02:57:13 +0000
> From: "Verma, Vishal L" <[email protected]>
> To: "[email protected]" <[email protected]>
> Cc: "[email protected]" <[email protected]>
> 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
>
>
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
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
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