From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752804AbcKRJnm (ORCPT ); Fri, 18 Nov 2016 04:43:42 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40318 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751527AbcKRJnk (ORCPT ); Fri, 18 Nov 2016 04:43:40 -0500 Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: <20161117234047.GE28177@dastard> References: <20161117234047.GE28177@dastard> <147938969703.13574.10295364502230379833.stgit@warthog.procyon.org.uk> <147938970382.13574.11581172952175034619.stgit@warthog.procyon.org.uk> To: Dave Chinner Cc: dhowells@redhat.com, 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 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26218.1479462218.1@warthog.procyon.org.uk> Date: Fri, 18 Nov 2016 09:43:38 +0000 Message-ID: <26219.1479462218@warthog.procyon.org.uk> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Fri, 18 Nov 2016 09:43:40 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dave Chinner wrote: > > STATX_ATTR_KERNEL_API File is kernel API (eg: procfs/sysfs) > > STATX_ATTR_REMOTE File is remote and needs network > > STATX_ATTR_FABRICATED File was made up by fs > > Every file is fabricated by a filesystem :P > > Perhaps you're wanting "virtual file" because it is has no physical > presence? Yeah - that might be a better name. The idea of FABRICATED is to note objects that have no actual existence in the backing store. Directories that had to be invented to act as mountpoints would be a good example of this. > > 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". > > 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! ;-) 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. David