From: Dave Chinner <david@fromorbit.com>
To: David Howells <dhowells@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
Date: Sat, 19 Nov 2016 08:41:06 +1100 [thread overview]
Message-ID: <20161118214106.GB31101@dastard> (raw)
In-Reply-To: <26219.1479462218@warthog.procyon.org.uk>
On Fri, Nov 18, 2016 at 09:43:38AM +0000, David Howells wrote:
> Dave Chinner <david@fromorbit.com> wrote:
> > > Fields in struct statx come in a number of classes:
> > >
> > > (0) stx_dev_*, stx_blksize.
> > >
> > > These are local system information and are always available.
> >
> > What does stx_blksize actually mean? It's completely ambiguous in
> > stat() because we don't actually report the physical block size
> > here - we report the "minimum unit of efficient IO" that we expect
> > applications to use. Please define :P
>
> Definition: "Same as struct stat::st_blksize".
So it is still defined as "mostly useless", then? :/
> > > The following test program can be used to test the statx system call:
> > >
> > > samples/statx/test-statx.c
> > >
> > > Just compile and run, passing it paths to the files you want to examine.
> > > The file is built automatically if CONFIG_SAMPLES is enabled.
> >
> > Can we get xfstests written to exercise and validate all this
> > functionality, please? I'd suggest that adding xfs_io support for
> > the statx syscall would be far more useful for xfstests than a
> > standalone test program, too. We already have equivalent stat()
> > functionality in xfs_io and that's used quite a bit in xfstests....
>
> Feel free to write some! ;-)
No, not my job. It is the responsibility of the person added new
functionality to write the validity tests for everyone else to use.
> But I need a simple standalone test program to be able to test what I write,
> and I've no inclination to wheel out huge testsuites for an interface that
> people are still arguing about and wanting changed.
The test suite should be developed concurrently with the code. You
know, best software engineering practices and all that. Just a small
example: Darrick landed 100+ reflink related tests in xfstests
before we merged the XFS reflink functionality. And that's just for
XFS - this is something that /all filesystems/ need to work
correctly with, so it's even more important that we have tests to
verify functionality /before/ it gets merged.
Quite frankly, I think this has to be an unconditional requirement
for such generic, expandabled new syscall functionality - either we
get test coverage for it before merge, or we don't merge it. We've
demonstrated time and time again that shit doesn't work if it's not
tested and cannot be widely verified by independent filesystem
developers.
Again, I'll use the example of Darrick's reflink tests - that
exposed multiple bugs in the btrfs reflink implementation that
nobody knew existed because /they'd never been tested/. And we've
found several subtle differences in fs implementations that would
seriously confuse applications (e.g. how a range of "0 bytes" is
treated by the filesystem) as a result of adding tests to exercise
these exact semantics.
These are the sorts of issues we need test coverage to avoid, and we
need it before merge, not after.
Cheers,
Dave.
>
> David
>
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2016-11-18 21:41 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-17 13:34 [RFC][PATCH 0/4] Enhanced file stat system call David Howells
2016-11-17 13:35 ` [PATCH 1/4] statx: Add a system call to make enhanced file info available David Howells
2016-11-17 18:39 ` Jeff Layton
2016-11-18 2:32 ` Andreas Dilger
2016-11-18 8:59 ` David Howells
2016-11-18 8:59 ` David Howells
2016-11-18 9:25 ` Andreas Dilger
2016-11-18 9:25 ` Andreas Dilger
2016-11-17 23:40 ` Dave Chinner
2016-11-18 3:28 ` Andreas Dilger
2016-11-18 22:07 ` Dave Chinner
2016-11-18 22:54 ` David Howells
2016-11-19 22:43 ` Dave Chinner
2016-11-21 14:30 ` One Thousand Gnomes
2016-11-21 20:43 ` Dave Chinner
2016-11-22 10:39 ` David Howells
2016-11-22 13:55 ` Jeff Layton
2016-11-22 20:58 ` Dave Chinner
2016-11-18 9:53 ` David Howells
2016-11-18 8:48 ` David Howells
2016-11-18 12:01 ` Jeff Layton
2016-11-18 9:36 ` David Howells
2016-11-18 17:17 ` Jeff Layton
2016-11-18 18:04 ` David Howells
2016-11-18 18:54 ` Jeff Layton
2016-11-18 19:08 ` David Howells
2016-11-18 9:43 ` David Howells
2016-11-18 21:41 ` Dave Chinner [this message]
2016-11-18 22:24 ` David Howells
2016-11-18 10:29 ` David Howells
2016-11-18 10:29 ` David Howells
2016-11-18 21:27 ` Dave Chinner
2016-11-18 21:48 ` David Howells
2016-11-18 21:48 ` David Howells
2016-11-18 22:17 ` Dave Chinner
2016-11-18 22:17 ` Dave Chinner
2016-11-19 10:21 ` Michael Kerrisk (man-pages)
2016-11-17 13:35 ` [PATCH 2/4] statx: Ext4: Return enhanced file attributes David Howells
2016-11-18 3:30 ` Andreas Dilger
2016-11-17 13:35 ` [PATCH 3/4] statx: NFS: " David Howells
2016-11-17 13:35 ` [PATCH 4/4] statx: AFS: " David Howells
2016-11-18 3:34 ` Andreas Dilger
2016-11-18 8:47 ` David Howells
2016-11-17 14:39 ` [RFC][PATCH 0/4] Enhanced file stat system call One Thousand Gnomes
2016-11-17 15:10 ` Michael Kerrisk
2016-11-17 16:33 ` David Howells
2016-11-17 16:45 ` David Howells
2016-11-17 20:00 ` J. Bruce Fields
2016-11-18 2:30 ` Andreas Dilger
2016-11-18 4:29 ` NeilBrown
2016-11-18 13:41 ` One Thousand Gnomes
2016-11-18 13:49 ` David Howells
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=20161118214106.GB31101@dastard \
--to=david@fromorbit.com \
--cc=dhowells@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@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.