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

NeilBrown
2016-05-04T23:56:58Z

[-- Attachment #1: Type: text/plain, Size: 2736 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]