From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752651AbcEJNVO (ORCPT ); Tue, 10 May 2016 09:21:14 -0400 Received: from mail-qk0-f178.google.com ([209.85.220.178]:33891 "EHLO mail-qk0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752577AbcEJNVJ (ORCPT ); Tue, 10 May 2016 09:21:09 -0400 Message-ID: <1462886465.20038.6.camel@poochiereds.net> Subject: Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available From: Jeff Layton To: Christoph Hellwig Cc: David Howells , linux-fsdevel@vger.kernel.org, linux-afs@vger.kernel.org, linux-nfs@vger.kernel.org, samba-technical@lists.samba.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org Date: Tue, 10 May 2016 09:21:05 -0400 In-Reply-To: <20160510070044.GA30896@infradead.org> References: <20160429125736.23636.47874.stgit@warthog.procyon.org.uk> <20160429125743.23636.85219.stgit@warthog.procyon.org.uk> <20160508083543.GA14316@infradead.org> <1462795378.4481.31.camel@poochiereds.net> <20160510070044.GA30896@infradead.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.1 (3.20.1-1.fc24) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2016-05-10 at 00:00 -0700, Christoph Hellwig wrote: > On Mon, May 09, 2016 at 08:02:58AM -0400, Jeff Layton wrote: > > > > AT_FORCE_ATTR_SYNC can be set in flags.????This will require a > > > > network > > > > filesystem to synchronise its attributes with the server. > > > > > > > > AT_NO_ATTR_SYNC can be set in flags.????This will suppress > > > > synchronisation > > > > with the server in a network filesystem.????The resulting > > > > values should be > > > > considered approximate. > > > > > > And what happens if neither is set? > > > > > > > I'd suggest we have the documentation state that the lack of either > > flag leaves it up to the filesystem. In the case of NFS, you'd get > > "normal" attribute cache behavior, for instance which is governed > > by > > the ac* attributes. > > > > We should also note that in the case of something like > > AT_NO_ATTR_SYNC > > on NFS, you might _still_ end up talking to the server if the > > client > > has nothing in-core for that inode. > > File systems specific "legacy" defaults are a bad idea.  If we can't > describe the semantics we should not allow them, never mind making > the the default.  I'd strongly suggest picking one of the above flags > as the default behavior and only allowing the other as optional flag. > I suspect NO_SYNC is the better one for the flag, as otherwise people > will be surprised once they test their default case on a network > filesystem. Ok, that's a good point. So basically you suggest that xstat should always have FORCE_SYNC semantics unless the NO_SYNC flag is set? Given that we don't need to worry about legacy users with this interface, that seems like a reasonable approach to me.   -- Jeff Layton From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Layton Subject: Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available Date: Tue, 10 May 2016 09:21:05 -0400 Message-ID: <1462886465.20038.6.camel@poochiereds.net> References: <20160429125736.23636.47874.stgit@warthog.procyon.org.uk> <20160429125743.23636.85219.stgit@warthog.procyon.org.uk> <20160508083543.GA14316@infradead.org> <1462795378.4481.31.camel@poochiereds.net> <20160510070044.GA30896@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: David Howells , linux-fsdevel@vger.kernel.org, linux-afs@vger.kernel.org, linux-nfs@vger.kernel.org, samba-technical@lists.samba.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org To: Christoph Hellwig Return-path: In-Reply-To: <20160510070044.GA30896@infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-ext4.vger.kernel.org On Tue, 2016-05-10 at 00:00 -0700, Christoph Hellwig wrote: > On Mon, May 09, 2016 at 08:02:58AM -0400, Jeff Layton wrote: > > > > AT_FORCE_ATTR_SYNC can be set in flags.????This will require a > > > > network > > > > filesystem to synchronise its attributes with the server. > > > >=20 > > > > AT_NO_ATTR_SYNC can be set in flags.????This will suppress > > > > synchronisation > > > > with the server in a network filesystem.????The resulting > > > > values should be > > > > considered approximate. > > >=20 > > > And what happens if neither is set? > > >=20 > >=20 > > I'd suggest we have the documentation state that the lack of either > > flag leaves it up to the filesystem. In the case of NFS, you'd get > > "normal" attribute cache behavior, for instance which is governed > > by > > the ac* attributes. > >=20 > > We should also note that in the case of something like > > AT_NO_ATTR_SYNC > > on NFS, you might _still_ end up talking to the server if the > > client > > has nothing in-core for that inode. >=20 > File systems specific "legacy" defaults are a bad idea.=C2=A0=C2=A0If= we can't > describe the semantics we should not allow them, never mind making > the the default.=C2=A0=C2=A0I'd strongly suggest picking one of the a= bove flags > as the default behavior and only allowing the other as optional flag. > I suspect NO_SYNC is the better one for the flag, as otherwise people > will be surprised once they test their default case on a network > filesystem. Ok, that's a good point. So basically you suggest that xstat should always have FORCE_SYNC semantics unless the NO_SYNC flag is set? Given that we don't need to worry about legacy users with this interface, that seems like a reasonable approach to me. =C2=A0 --=20 Jeff Layton -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html