Messages in this thread | | | From | NeilBrown <> | Date | Thu, 05 May 2016 09:56:58 +1000 | Subject | Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available |
| |
On Fri, Apr 29 2016, David Howells wrote:
> Add a system call to make extended file information available, including > file creation time, inode version and data version where available through > the underlying filesystem. > > > ======== > OVERVIEW > ========
I think all this documentation is invaluable - thanks. I would really like to see much of it in Documentation/filesystems/something.txt rather than just in the commit log.
> > The defined bits in the st_information field give local system data on a > file, how it is accessed, where it is and what it does:
These bits form a channel for communication between the filesystem developer and the application writer. As such we should be sure that channel actually communicates meaning...
> > STATX_INFO_ENCRYPTED File is encrypted > STATX_INFO_TEMPORARY File is temporary
What is "temporary"? Is it a statement about quality of storage technology (will be destroyed by reboot) or intention of creator (created with O_TMPFILE) or something else?
> STATX_INFO_FABRICATED File was made up by filesystem > STATX_INFO_KERNEL_API File is kernel API (eg: procfs/sysfs)
What is the difference between these two? Both are synthesized by the kernel. Maybe the "KERNEL_API" is declared never to change its meaning, while the fabricated one doesn't make a "stable API" promise?
What is the difference between fabricating a file from a bunch of blocks spread over a storage device, and fabricating a file from a single field in the super-block?
> STATX_INFO_REMOTE File is remote
How far is "remote"? Does Infiniband count? Fibre channel? iSCSI? Is a file on a loop-back mounted NFS filesystem more remote than a fibre-channel connection to the next town?
Or is this relative? Within a filesystem there are "remote" files and "non-remote" files and the distinction is filesystem-dependant??
> STATX_INFO_AUTOMOUNT Dir is automount trigger > STATX_INFO_AUTODIR Dir provides unlisted automounts
I think this last one means that there are names in the directory which may not appear in "readdir" but will respond to "stat". I would prefer the description to match the behavior without necessarily implying that those names will be automounts. e.g STATX_INFO_INCOMPLETE_READDIR getdents may not report all names that respond to stat
> STATX_INFO_NONSYSTEM_OWNERSHIP File has non-system ownership details
This probably is a well defined meaning that I just don't have the context to understand. For me, more words would help here.
I don't object to any of these flag. I just want to be sure that I understand them. I am generally in favour this functionality going in promptly.
Thanks, NeilBrown [unhandled content-type:application/pgp-signature] | |