From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752173AbcKRCqD (ORCPT ); Thu, 17 Nov 2016 21:46:03 -0500 Received: from mail-it0-f65.google.com ([209.85.214.65]:35127 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751225AbcKRCp7 (ORCPT ); Thu, 17 Nov 2016 21:45:59 -0500 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 X-Pgp-Agent: GPGMail From: Andreas Dilger In-Reply-To: <20161117200026.GE20937@fieldses.org> Date: Thu, 17 Nov 2016 19:30:25 -0700 Cc: David Howells , One Thousand Gnomes , 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" X-Mailer: Apple Mail (2.3124) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --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 = wrote: >=20 > On Thu, Nov 17, 2016 at 04:45:45PM +0000, David Howells wrote: >> One Thousand Gnomes 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--