Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available

[David Howells]

Dave Chinner <david@xxxxxxxxxxxxx> 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