xfstest status on current kernels

xfstest status on current kernels

[Steve French]

Is there a list somewhere of the full set of xfstests that are
expected to run (and presumably pass) on current Linux kernels for the
local file systems (ext4, btrfs and/or xfs)?

I want to make sure that I don't accidentally ignore a test (e.g. test
generic/003 doesn't run with a message " [not run] relatime not
supported by the current kernel" and want to make sure I am not
missing something).

Obviously cifs/smb3 and nfs are not going to run all the tests that
ext4, btrfs and xfs do but it is easy to leave a test out for the
wrong reasons (build dependency etc.) so want to know the list that
should run on a local Linux fs.

-- 
Thanks,

Steve

Re: xfstest status on current kernels

[Dave Chinner]

On Wed, Nov 12, 2014 at 05:31:20PM -0600, Steve French wrote:
> Is there a list somewhere of the full set of xfstests that are
> expected to run (and presumably pass) on current Linux kernels for the
> local file systems (ext4, btrfs and/or xfs)?

No.

You should expect all supported tests in the auto group to run for a
given filesystem. i.e. "./check -g auto" should run all the tests a
given filesytem supports, there should be very few failures, and the
only tests that _notrun are tests that aren't supported by either
you kernel or filesystem config.

> I want to make sure that I don't accidentally ignore a test (e.g. test
> generic/003 doesn't run with a message " [not run] relatime not
> supported by the current kernel" and want to make sure I am not
> missing something).

You need to such things yourself and determine if the test should
have run for your given test configuration.

e.g. on XFS you'll get stuff like this if you run with CRCs enabled:

xfs/287 0s ... [not run] 16 bit project IDs not supported on /dev/vdb

because such filesystem only support 32 bit project IDs on disk.

Or if you are missing stuff in your kernel config:

xfs/279  [not run] scsi_debug module not found

Or you aren't running with special subsystems enabled:

xfs/300 1s ... [not run] SELinux not enabled

Or your hardware is lacking in functionality:

generic/260      [not run] FITRIM not supported on /dev/vdb

or test tools weren't built due to missing libraries:

generic/010      [not run] dbtest was not built for this platform

or the filesystem doesn't support the functionality being tested:

generic/024 1s ... [not run] fs doesn't support RENAME_NOREPLACE

All of these things are issues local to the setup being tested, and
so there really isn't a canonical list of what should or shouldn't
run...

> Obviously cifs/smb3 and nfs are not going to run all the tests that
> ext4, btrfs and xfs do but it is easy to leave a test out for the
> wrong reasons (build dependency etc.) so want to know the list that
> should run on a local Linux fs.

Tests should notrun if tests tools were not built due to missing
build dependencies.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: xfstest status on current kernels

[Steve French]

On Wed, Nov 12, 2014 at 9:26 PM, Dave Chinner <david@fromorbit.com> wrote:
> On Wed, Nov 12, 2014 at 05:31:20PM -0600, Steve French wrote:

>> I want to make sure that I don't accidentally ignore a test (e.g. test
>> generic/003 doesn't run with a message " [not run] relatime not
>> supported by the current kernel" and want to make sure I am not
>> missing something).
>
> You need to such things yourself and determine if the test should
> have run for your given test configuration.

I have been going through these one at a time as I have time (to
see if they are workable on cifs/smb3 etc) - but it can get
tricky (e.g. in this case relatime may be default behavior for fs so
lack of a mount option with this exact name may be unnecessarily
disabling this one on some fs)

> or test tools weren't built due to missing libraries:
>
> generic/010      [not run] dbtest was not built for this platform

This is a good example, and one run that I had run into a month or
two ago (at first I had assumed at first
that it was not runnable on Linux, and then eventually
figured out the build dependencies for it to work on Ubuntu and Fedora)
Not always clear to me which of these tests are never going to work on Linux.


-- 
Thanks,

Steve

Re: xfstest status on current kernels

[Eric Sandeen]

On 11/12/14 9:38 PM, Steve French wrote:
> On Wed, Nov 12, 2014 at 9:26 PM, Dave Chinner <david@fromorbit.com> wrote:
>> On Wed, Nov 12, 2014 at 05:31:20PM -0600, Steve French wrote:
> 
>>> I want to make sure that I don't accidentally ignore a test (e.g. test
>>> generic/003 doesn't run with a message " [not run] relatime not
>>> supported by the current kernel" and want to make sure I am not
>>> missing something).
>>
>> You need to such things yourself and determine if the test should
>> have run for your given test configuration.

out of curiosity, what fs/kernel fails a "-o relatime" mount?

> I have been going through these one at a time as I have time (to
> see if they are workable on cifs/smb3 etc) - but it can get
> tricky (e.g. in this case relatime may be default behavior for fs so
> lack of a mount option with this exact name may be unnecessarily
> disabling this one on some fs)
> 
>> or test tools weren't built due to missing libraries:
>>
>> generic/010      [not run] dbtest was not built for this platform

dbtest used to be fiddly to build, but it builds here.

#ifdef HAVE_GDBM_NDBM_H_
#include <gdbm/ndbm.h>
#elif HAVE_GDBM_NDBM_H
#include <gdbm-ndbm.h>
#elif HAVE_GDBM_H
#include <gdbm.h>
#elif HAVE_NDBM_H
#include <ndbm.h>
#else
bozo!
#endif

yeah ....

well, we should at least list devel package dependencies for the entire
suite, I think, so as many people as possible can get everything going
as painlessly as possible.


our qe has this in a specfile:

BuildRequires:	autoconf, libtool, e2fsprogs-devel, xfsprogs-devel
BuildRequires:	libacl-devel, libattr-devel, libaio-devel

but that won't build dbtest!

> This is a good example, and one run that I had run into a month or
> two ago (at first I had assumed at first
> that it was not runnable on Linux, and then eventually
> figured out the build dependencies for it to work on Ubuntu and Fedora)

Since you had the ... privilege of getting it built from scratch, if you
wanted to submit a patch to the docs to clearly describe dependencies, that'd
be great.  :)

> Not always clear to me which of these tests are never going to work on Linux.

unless it says:

xfs/114	 [not run] not suitable for this OS: Linux

it should run on Linux.

There are only a few:

# grep _supported_os tests/*/??? | grep -vi linux
tests/generic/093:_supported_os IRIX
tests/generic/097:_supported_os IRIX
tests/generic/099:_supported_os IRIX
tests/udf/098:_supported_os IRIX
tests/udf/101:_supported_os IRIX
tests/xfs/057:_supported_os IRIX
tests/xfs/058:_supported_os IRIX
tests/xfs/095:_supported_os IRIX
tests/xfs/114:_supported_os IRIX
tests/xfs/115:_supported_os IRIX

-Eric

Re: xfstest status on current kernels

[Dave Chinner]

On Wed, Nov 12, 2014 at 09:38:45PM -0600, Steve French wrote:
> On Wed, Nov 12, 2014 at 9:26 PM, Dave Chinner <david@fromorbit.com> wrote:
> > On Wed, Nov 12, 2014 at 05:31:20PM -0600, Steve French wrote:
> 
> >> I want to make sure that I don't accidentally ignore a test (e.g. test
> >> generic/003 doesn't run with a message " [not run] relatime not
> >> supported by the current kernel" and want to make sure I am not
> >> missing something).
> >
> > You need to such things yourself and determine if the test should
> > have run for your given test configuration.
> 
> I have been going through these one at a time as I have time (to
> see if they are workable on cifs/smb3 etc) - but it can get
> tricky (e.g. in this case relatime may be default behavior for fs so
> lack of a mount option with this exact name may be unnecessarily
> disabling this one on some fs)

I don't think that's the case. Any kernel that supports relatime
supports the relatime mount option. It doesn't matter if the
filesystem defaults to it or not, MS_RELATIME is a valid mount
flag on all supported kernels.

I can't see where a current kernel would reject an attempt to mount
with the MS_RELATIME flag set, so if you're seeing that fail either
the mount program for your filesystem type is rejecting it or you've
got a very old kernel....

> > or test tools weren't built due to missing libraries:
> >
> > generic/010      [not run] dbtest was not built for this platform
> 
> This is a good example, and one run that I had run into a month or
> two ago (at first I had assumed at first
> that it was not runnable on Linux, and then eventually
> figured out the build dependencies for it to work on Ubuntu and Fedora)
> Not always clear to me which of these tests are never going to work on Linux.

We require the supported OS for the test to be defined in every
test. it's pretty easy to check:

$ grep _supported_os tests/generic/010
_supported_os IRIX Linux
$

Try to run a test that isn't supported on Linux and you get:

xfs/095  [not run] not suitable for this OS: Linux

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: xfstest status on current kernels

[Steve French]

On Wed, Nov 12, 2014 at 10:22 PM, Dave Chinner <david@fromorbit.com> wrote:
> On Wed, Nov 12, 2014 at 09:38:45PM -0600, Steve French wrote:
>> On Wed, Nov 12, 2014 at 9:26 PM, Dave Chinner <david@fromorbit.com> wrote:
>> > On Wed, Nov 12, 2014 at 05:31:20PM -0600, Steve French wrote:
>>
>> >> I want to make sure that I don't accidentally ignore a test (e.g. test
>> >> generic/003 doesn't run with a message " [not run] relatime not
>> >> supported by the current kernel" and want to make sure I am not
>> >> missing something).
>> I have been going through these one at a time as I have time (to
>> see if they are workable on cifs/smb3 etc) - but it can get
>> tricky (e.g. in this case relatime may be default behavior for fs so
>> lack of a mount option with this exact name may be unnecessarily
>> disabling this one on some fs)
>
> I don't think that's the case. Any kernel that supports relatime
> supports the relatime mount option. It doesn't matter if the
> filesystem defaults to it or not, MS_RELATIME is a valid mount
> flag on all supported kernels.

relatime is rejected by the kernel cifs.ko driver (I will need to fix
that) but should be ignored.  Looking at the xfstest logs looks like
noatime is going to have the same problem as well.
I will fix these in the cifs mount parsing.

>
> We require the supported OS for the test to be defined in every
> test. it's pretty easy to check:
>
> $ grep _supported_os tests/generic/010
> _supported_os IRIX Linux
> $
>
> Try to run a test that isn't supported on Linux and you get:
>
> xfs/095  [not run] not suitable for this OS: Linux

If that is the only case where it is Linux specific
that will make it easier to distinguish these from the cases
like test 3 where it is mount parsing related (despite
the message).


-- 
Thanks,

Steve

Re: xfstest status on current kernels

[Dave Chinner]

On Wed, Nov 12, 2014 at 10:33:37PM -0600, Steve French wrote:
> On Wed, Nov 12, 2014 at 10:22 PM, Dave Chinner <david@fromorbit.com> wrote:
> > On Wed, Nov 12, 2014 at 09:38:45PM -0600, Steve French wrote:
> >> On Wed, Nov 12, 2014 at 9:26 PM, Dave Chinner <david@fromorbit.com> wrote:
> >> > On Wed, Nov 12, 2014 at 05:31:20PM -0600, Steve French wrote:
> >>
> >> >> I want to make sure that I don't accidentally ignore a test (e.g. test
> >> >> generic/003 doesn't run with a message " [not run] relatime not
> >> >> supported by the current kernel" and want to make sure I am not
> >> >> missing something).
> >> I have been going through these one at a time as I have time (to
> >> see if they are workable on cifs/smb3 etc) - but it can get
> >> tricky (e.g. in this case relatime may be default behavior for fs so
> >> lack of a mount option with this exact name may be unnecessarily
> >> disabling this one on some fs)
> >
> > I don't think that's the case. Any kernel that supports relatime
> > supports the relatime mount option. It doesn't matter if the
> > filesystem defaults to it or not, MS_RELATIME is a valid mount
> > flag on all supported kernels.
> 
> relatime is rejected by the kernel cifs.ko driver (I will need to fix
> that) but should be ignored.

relatime should never get to the kernel as a string fs specific
string. It's supposed to be parsed by the mount binary and passed
as the MS_RELATIME flag to the kernel, not as a string.

> Looking at the xfstest logs looks like
> noatime is going to have the same problem as well.
> I will fix these in the cifs mount parsing.

Again: MS_NOATIME.

This sounds like a bug in the mount.cifs binary, not the kernel.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: xfstest status on current kernels

[Steve French]

On Wed, Nov 12, 2014 at 10:44 PM, Dave Chinner <david@fromorbit.com> wrote:
> On Wed, Nov 12, 2014 at 10:33:37PM -0600, Steve French wrote:
>> On Wed, Nov 12, 2014 at 10:22 PM, Dave Chinner <david@fromorbit.com> wrote:
>> > On Wed, Nov 12, 2014 at 09:38:45PM -0600, Steve French wrote:
>> >> On Wed, Nov 12, 2014 at 9:26 PM, Dave Chinner <david@fromorbit.com> wrote:
>> >> > On Wed, Nov 12, 2014 at 05:31:20PM -0600, Steve French wrote:
>> >>
>> >> >> I want to make sure that I don't accidentally ignore a test (e.g. test
>> >> >> generic/003 doesn't run with a message " [not run] relatime not
>> >> >> supported by the current kernel" and want to make sure I am not
>> >> >> missing something).
>> >> I have been going through these one at a time as I have time (to
>> >> see if they are workable on cifs/smb3 etc) - but it can get
>> >> tricky (e.g. in this case relatime may be default behavior for fs so
>> >> lack of a mount option with this exact name may be unnecessarily
>> >> disabling this one on some fs)
>> >
>> > I don't think that's the case. Any kernel that supports relatime
>> > supports the relatime mount option. It doesn't matter if the
>> > filesystem defaults to it or not, MS_RELATIME is a valid mount
>> > flag on all supported kernels.
>>
>> relatime is rejected by the kernel cifs.ko driver (I will need to fix
>> that) but should be ignored.
>
> relatime should never get to the kernel as a string fs specific
> string. It's supposed to be parsed by the mount binary and passed
> as the MS_RELATIME flag to the kernel, not as a string.
>
>> Looking at the xfstest logs looks like
>> noatime is going to have the same problem as well.
>> I will fix these in the cifs mount parsing.
>
> Again: MS_NOATIME.
>
> This sounds like a bug in the mount.cifs binary, not the kernel.

Yes - that is actually where I fixed it (mount.cifs.c). It is easier
to catch it there.

I need to look at what test 3 is doing more carefully since it is
also passing nodiratime and strictatime (which will
also cause problems if not parsed properly) but this test is
unlikely to work across the network due to timestamp
caching issues.   Even turning off metadata caching
(actimeo=0 on cifs mount) only gets partway through this
test on a cifs mount.  It will fail at

"access time has changed for dir2 after file creation"

This (generic/test3) will likely be one that we want to continue
to skip on a network fs.

-- 
Thanks,

Steve

Re: xfstest status on current kernels

[Dave Chinner]

On Wed, Nov 12, 2014 at 11:09:44PM -0600, Steve French wrote:
> This (generic/test3) will likely be one that we want to continue
> to skip on a network fs.

Then you want to add send a patch that adds CIFS to very recent
check added for NFS:

f72abf5 generic: skip atime related tests on NFS

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com