Subject: Re: [RFC][PATCH 0/4] Enhanced file stat system call
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_73964B12-7311-4E9A-840B-AFED6D8B17AD"; protocol="application/pgp-signature"; micalg=pgp-sha256
From: Andreas Dilger <adilger@dilger.ca>
In-Reply-To: <20161117200026.GE20937@fieldses.org>
Date: Thu, 17 Nov 2016 19:30:25 -0700
Cc: David Howells <dhowells@redhat.com>,
        One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Message-Id: <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>
To: "J. Bruce Fields" <bfields@fieldses.org>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 5004
Lines: 147


--Apple-Mail=_73964B12-7311-4E9A-840B-AFED6D8B17AD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On Nov 17, 2016, at 1:00 PM, J. Bruce Fields <bfields@fieldses.org> =
wrote:
>=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 =
flush
>>>>     buffers and go to the server, even if it thinks its cached =
attributes
>>>>     are up to date.
>>>=20
>>> That seems an odd way to do it. Wouldn't it be cleaner and more =
flexible
>>> 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() =
equivalent 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 =
than
>>> 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 =
like
>>> installers and also for sanity checking things like backup paths.
>>=20
>> There's a FILE_ATTRIBUTE_TEMPORARY that I could map for windows =
filesystems
>> 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 =
insane 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 =
local fs
>> on NBD?  Perhaps I should drop 'REMOTE' for now.  It sounds like =
something
>> 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.

Cheers, Andreas


--Apple-Mail=_73964B12-7311-4E9A-840B-AFED6D8B17AD
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIVAwUBWC5nwXKl2rkXzB/gAQjOUBAAjmZAmzVeqCihQ3i6zves4ThE2iSjiry4
GKXjjaWaLM63gEVonM/LCS8moa/1J1TJPpwxWzUapAlAM8XRwmBl2GwSrnbXDq2r
on5IbY8KlpM0POvUI/QMULQ/yx5HANE6+468cXqo+Xtuhrq+gU3otf07QZNpaubC
kmQmp6hJslMRtZ1Wq9ZZX+4frluuYF3Z5fLFdypJx5W8Gvxfiux1jg9HUBBX5r8H
kf0/tK508T/7+P9a6EJ/EWGRKc8M/LOWlkf/eGqiQy90yuYG05e/PllCxh3ISw7c
FSC/nisdBs33L6e1a6GfFcB75FIbKq+bA5zJUYGZg3tpudpYvdCk2JWCEzZWrGZz
ssBbRfD0jyoPp0iZJ9lz6YJrgLBlK9rHsdtOk+a/41VgeYraQ1PhTEaehPw+BjsF
7FoDxrUc6ZVgdVuxWMuR7puyyNnseJeoGwCe/EhTpq5iLH5VzUvtpZmUO7r0buzH
2mTLLQO6EqsMAX99flWtP72ELOV5OzayJQop3KEr+8jbohQ0WHYa0Zwc/o2z2NBw
ka69MR4C96xN8AFw/cqAHsn+Atzk7P73wbzxAvQl2ofe/CiY7gh8XCGVoMflq6w6
urfFl0QiQJuc6kT/ixMts09SL4SE9ul8Cf6OxVVAQK8mh/cFlVThwEimKwYdQo9x
FslRrb1URcM=
=mhup
-----END PGP SIGNATURE-----

--Apple-Mail=_73964B12-7311-4E9A-840B-AFED6D8B17AD--