Date: Sat, 19 Nov 2016 08:41:06 +1100
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
Message-ID: <20161118214106.GB31101@dastard>
References: <20161117234047.GE28177@dastard>
 <147938969703.13574.10295364502230379833.stgit@warthog.procyon.org.uk>
 <147938970382.13574.11581172952175034619.stgit@warthog.procyon.org.uk>
 <26219.1479462218@warthog.procyon.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <26219.1479462218@warthog.procyon.org.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3019
Lines: 76

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