From: Eryu Guan <eguan@redhat.com>
To: David Howells <dhowells@redhat.com>
Cc: linux-xfs@vger.kernel.org, hch@infradead.org, amir73il@gmail.com,
david@fromorbit.com, fstests@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 2/4] xfstests: Add first statx test [ver #5]
Date: Wed, 5 Apr 2017 18:38:09 +0800 [thread overview]
Message-ID: <20170405103809.GY22845@eguan.usersys.redhat.com> (raw)
In-Reply-To: <149132131706.18980.7074156386090748482.stgit@warthog.procyon.org.uk>
On Tue, Apr 04, 2017 at 04:55:17PM +0100, David Howells wrote:
> Add a statx test script that does the following:
>
> (1) Creates one each of the various types of file object and creates a
> hard link to the regular file.
>
> Note that the creation of an AF_UNIX socket is done with netcat in a
> bash coprocessing thread. This might be best done with another
> in-house helper to avoid a dependency on nc.
>
> (2) Invokes the C test program included in this patch after the creation
> and hands it a list of things to check appropriate to each object.
>
> (3) Asks the test program to check the creation time of each object
> against that of the preceding object.
>
> (4) Makes various tests on the timestamps of the hardlinked file.
>
> The patch also creates a C[*] test program to do the actual stat checking.
> The test program then does the following:
>
> (1) Compares the output of statx() to that of fstatat().
>
> (2) Optionally compares the timestamps to see that they're sensibly
> ordered with respect to each other.
>
> (3) Optionally compares the timestamps to those of a reference file.
>
> (4) Optionally compares the timestamps to a specified time.
>
> (5) Optionally compares selected stats to values specified on the command
> line.
>
> (6) Optionally compares all the stats to those of a reference file,
> requiring them to be the same (hard link checking).
>
> For example:
>
> ./src/stat_test /dev/null \
> stx_type=char \
> stx_rdev_major=3 \
> stx_rdev_minor=8 \
> stx_nlink=1 \
> ref=/dev/zero \
> ts=B,b
>
> The test program can also be given a --check-statx parameter to give a
> quick exit code-based answer on whether statx() exists within the kernel.
>
> [*] Note that it proved much easier to do this in C than trying to do it in
> shell script and trying parsing the output of xfs_io. Using xfs_io has
> other pitfalls also: it wants to *open* the file, even if the file is
> not an appropriate type for this or does not grant permission to do so.
> I can get around this by opening O_PATH, but then xfs_io fails to
> handle XFS files because it wants to issue ioctls on every fd it opens.
>
> Signed-off-by: David Howells <dhowells@redhat.com>
btrfs fails this test as:
Test statx on a directory
+[!] stx_nlink differs, 1 != 2
+Failed
+stat_test failed
And it's the only filesystem I've tested that fails this test, is this
a known failure? (Tried extN, xfs, btrfs, NFSv4.0/1/2, 4.11-rc5 kernel)
Thanks,
Eryu
next prev parent reply other threads:[~2017-04-05 10:38 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-04 15:55 [PATCH 1/4] xfstests: Add an auxiliary program to create an AF_UNIX socket [ver #5] David Howells
2017-04-04 15:55 ` [PATCH 2/4] xfstests: Add first statx test " David Howells
2017-04-05 10:38 ` Eryu Guan [this message]
2017-04-05 10:53 ` Does btrfs get nlink on directories wrong? -- was " David Howells
2017-04-05 12:30 ` David Sterba
2017-04-05 12:32 ` Amir Goldstein
2017-04-08 15:43 ` Eryu Guan
2017-04-08 15:43 ` Eryu Guan
2017-04-08 21:02 ` David Howells
2017-04-04 15:55 ` [PATCH 3/4] xfstests: Partially expand the documentation " David Howells
2017-04-05 10:42 ` Eryu Guan
2017-04-05 10:55 ` David Howells
2017-04-05 10:59 ` Should xfstest generic/388 be using _require_command for fsstress? David Howells
2017-04-05 11:10 ` Eryu Guan
2017-04-05 11:17 ` David Howells
2017-04-05 11:32 ` Eryu Guan
2017-04-04 15:55 ` [PATCH 4/4] xfstests: Check the stx_attributes settable by chattr [ver #5] David Howells
2017-04-05 10:52 ` Eryu Guan
2017-04-05 11:11 ` David Howells
2017-04-05 11:30 ` Eryu Guan
2017-04-05 12:25 ` David Howells
2017-04-06 3:17 ` Eryu Guan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170405103809.GY22845@eguan.usersys.redhat.com \
--to=eguan@redhat.com \
--cc=amir73il@gmail.com \
--cc=david@fromorbit.com \
--cc=dhowells@redhat.com \
--cc=fstests@vger.kernel.org \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.