Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752730AbcKRVli (ORCPT ); Fri, 18 Nov 2016 16:41:38 -0500 Received: from ipmail06.adl6.internode.on.net ([150.101.137.145]:27722 "EHLO ipmail06.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751799AbcKRVlg (ORCPT ); Fri, 18 Nov 2016 16:41:36 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2B6JAAQdS9YELuKLHleHAEBBAEBCgEBgzcBAQEBAR+BWIJ7g3mcNAQBBoEcjCGGN4QVgmuDMAICAQECgg1UAQIBAQEBAQIGAQEBAQEBAQE3RYRoAQEBAwE6HCMFCwgDDgoJJQ8FJQMHGhOIZAeuXItOAQEIAiUehVSFJId6ghIeBZRjhWiQZ4F7hHeJQI1bhAuBQxEMg0IfgXEqNIYJK4IPAQEB Date: Sat, 19 Nov 2016 08:41:06 +1100 From: Dave Chinner To: David Howells 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 List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3019 Lines: 76 On Fri, Nov 18, 2016 at 09:43:38AM +0000, David Howells wrote: > Dave Chinner 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