From: NeilBrown <neilb@suse.com>
To: Andreas Dilger <adilger@dilger.ca>,
        "J. Bruce Fields" <bfields@fieldses.org>
Date: Fri, 18 Nov 2016 15:29:57 +1100
Cc: David Howells <dhowells@redhat.com>,
        One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH 0/4] Enhanced file stat system call
In-Reply-To: <3852DE26-42A6-4AFF-AA9C-08C4E9837511@dilger.ca>
References: <20161117143904.4ae757b4@lxorguk.ukuu.org.uk> <147938969703.13574.10295364502230379833.stgit@warthog.procyon.org.uk> <15516.1479401145@warthog.procyon.org.uk> <20161117200026.GE20937@fieldses.org> <3852DE26-42A6-4AFF-AA9C-08C4E9837511@dilger.ca>
User-Agent: Notmuch/0.22.1 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-suse-linux-gnu)
Message-ID: <87h975fm0q.fsf@notabene.neil.brown.name>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
        micalg=pgp-sha256; protocol="application/pgp-signature"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 5444
Lines: 141

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Fri, Nov 18 2016, Andreas Dilger wrote:

> [ Unknown signature status ]
>
>> On Nov 17, 2016, at 1:00 PM, J. Bruce Fields <bfields@fieldses.org> wrot=
e:
>>=20
>> On Thu, Nov 17, 2016 at 04:45:45PM +0000, David Howells wrote:
>>> One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> wrote:
>>>=20
>>>>> (2) Lightweight stat (AT_STATX_DONT_SYNC): Ask for just those details=
 of
>>>>>     interest, and allow a network fs to approximate anything not of
>>>>>     interest, without going to the server.
>>>>>=20
>>>>> (3) Heavyweight stat (AT_STATX_FORCE_SYNC): Force a network fs to flu=
sh
>>>>>     buffers and go to the server, even if it thinks its cached attrib=
utes
>>>>>     are up to date.
>>>>=20
>>>> That seems an odd way to do it. Wouldn't it be cleaner and more flexib=
le
>>>> to give a timestamp of the oldest time you consider acceptable (and
>>>> obviously passing 0 indicates whatever you have)
>>>=20
>>> Perhaps, though adding 6-argument syscalls is apparently frowned upon.
>>>=20
>>>>> Note that no lstat() equivalent is required as that can be implemented
>>>>> through statx() with atflag =3D=3D 0.  There is also no fstat() equiv=
alent as
>>>>> that can be implemented through statx() with filename =3D=3D NULL and=
 the
>>>>> relevant fd passed as dfd.
>>>>=20
>>>> and dfd + a name gives you fstatat() ?
>>>=20
>>> Yes.
>>>=20
>>>> The cover note could be clearer on this.
>>>=20
>>> Fixed.
>>>=20
>>>> Should the fields really be split the way they are for times rather th=
an
>>>> a struct for each one so you can write code generically to handle one =
of
>>>> those rather than having to have a 4 way switch statement all the time.
>>>=20
>>> It depends.  Doing so leaves 16 bytes of hole in the structure.  I could
>>> ameliorate the wastage by using a union to overlay useful fields in the=
 gaps,
>>> but that's pretty icky and might be compiler dependent.
>>>=20
>>>> Another attribute that would be nice (but migt need some trivial device
>>>> layer tweaking) would be STATX_ATTR_VOLATILE for filesystems that will
>>>> probably evaporate on a reboot. That's useful information for tools li=
ke
>>>> installers and also for sanity checking things like backup paths.
>>>=20
>>> There's a FILE_ATTRIBUTE_TEMPORARY that I could map for windows filesys=
tems
>>> that could be used with this.
>>>=20
>>>> Remote needs to have clear semantics: is ext4fs over nbd 'remote' for
>>>> example ?
>>>=20
>>> Hmmm... Interesting question.  Probably should.  But you could be insan=
e and
>>> RAID an nbd and a local disk.  Further, does NFS over a loopback device=
 to
>>> nfsd on the same machine qualify as root?  What if that's exposing a lo=
cal fs
>>> on NBD?  Perhaps I should drop 'REMOTE' for now.  It sounds like someth=
ing
>>> that a GUI filemanager might find interesting, though.
>>=20
>> Sorry, I haven't been paying attention, just popping up for this, but:
>> "shared" might be a more useful term than "remote".
>>=20
>> A filesystem that may be mounted from more than one system is "shared".
>> Caching performance and semantics of such a filesystem are more
>> complicated since the filesystem may change out from under us.  This is
>> what makes e.g. the lightweight/heavyweight stat difference more
>> interesting in the shared case.
>>=20
>> The filesystem should be able to make that shared/unshared distinction
>> without knowledge of the storage it's sitting on top of.
>>=20
>> Answering your questions by that criterion:
>>=20
>> 	- ext4/nbd: not shared
>> 	- nfs/lo: shared
>>=20
>> But, it's fine with me to drop any features for now as long as we can
>> always add them later.
>
> Please, please, please, let's get the syscall and basic functionality
> landed first, and then nit-pick about extensions later.  This has been
> dragging on for _years_ and bike shedded to death.

I very much agree with this, but I think it will require dropping (not
replacing yet) things that do not have a well defined meaning, including

> 	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

Without clear guidance on how the filesystem should choose to set these,
and how a program should interpret them, they are worse than noise.
I imagine each could possibly be useful, but without clear unambiguous
documentation, they aren't.
So just remove them for now, and consider adding them once the core
syscall has landed.

NeilBrown

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJYLoPFAAoJEDnsnt1WYoG5T6cP/3R/oYHH1jPhplvzDPPl/g68
ZSPf0C0QfXanTc9TAi18fmXq6c0bBTnhq1tfWPLP11CkqYfzODpyXxZepnsIbbEX
s2++gxdSNslyVjTx3uXVvvueAexPQC5OyWA30iB98Jg6boqvHz0a/pJIWdxn+fOw
9bPRQOROc1QZUvYH22oqbi/2KAKGTuHMC6THOs4Kqdys/QDjz6q+R+O1qxwcqHkZ
UZ+iDQdgMkmTPkmYg3GHDAYq40EOw/N1+ZMI3HWcMAM9lhUbTuVsheCNd7YR1ASN
PmG/weERSdsL9eO7oOGcEPRswhi2qUbB5S49JmkpzuNGNGIS8vZi5svfP5zWDXvd
b0at8qMrWJGbyjxbcfnP0Pg4PimzE5YmdAFZIh9IzQ4P17yaAgoXqNbG4Ops48aM
tfuQbIcpdVz4njfoBu/uevgDYGdV1AD4MCldsLIeDif1DdLHUZcoRO7tCIt9o+ld
AP0EVRGj/XWanbBMIGNIINAyftGblY0E/FaraGQsz/4HpXYZaGtklfKtJiKOIXYS
TlsVcRu1IL4ZBQczT0m9orIx8vl60NLOaWx4BxXyB9phA/VTj4bIUmqBE2yQ+6Ab
U/BeLI88tUYrj6uJ90UIGWhJZkxrBdvd4kCdenSixqH1W9NkQgfkCo8USJgltrfd
dDacIyJum4OncJkb2oiU
=NqPz
-----END PGP SIGNATURE-----
--=-=-=--