Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751876AbdIUMpe (ORCPT ); Thu, 21 Sep 2017 08:45:34 -0400 Received: from mail-qk0-f181.google.com ([209.85.220.181]:43332 "EHLO mail-qk0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751681AbdIUMpc (ORCPT ); Thu, 21 Sep 2017 08:45:32 -0400 X-Google-Smtp-Source: AOwi7QAb0Ea4QBMz2X4sai7wohmSGlhvq0opCl+LMnLZEPIGuKLU/SN4yhTXBmaqfW+5ODr21aTN8bhfWBgRsRqfAxg= MIME-Version: 1.0 In-Reply-To: <20170920200409.uksexswwko54ymg3@cs.cmu.edu> References: <1505896805-12055-1-git-send-email-mszeredi@redhat.com> <1505896805-12055-4-git-send-email-mszeredi@redhat.com> <20170920200409.uksexswwko54ymg3@cs.cmu.edu> From: Miklos Szeredi Date: Thu, 21 Sep 2017 14:45:30 +0200 Message-ID: Subject: Re: [PATCH 03/10] coda: honor AT_STATX_DONT_SYNC To: Jan Harkes Cc: linux-fsdevel , lkml , Al Viro , David Howells Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1934 Lines: 50 On Wed, Sep 20, 2017 at 10:04 PM, Jan Harkes wrote: > On Wed, Sep 20, 2017 at 10:39:58AM +0200, Miklos Szeredi wrote: >> The description of this flag says "Don't sync attributes with the server". >> In other words: always use the attributes cached in the kernel and don't >> send network or local messages to refresh the attributes. > > What is the use case for this AT_STATX_DONT_SYNC flag? > > I'm asking because the Coda userspace client potentially has attributes > that are not cached in the kernel but can be (re-)validated without > network communication. So if we just care about avoiding network > traffic we could propagate the flag up to userspace. If we want to avoid > context switches, disk I/O and only check on what happens to be cached > in the kernel the current approach works fine. It's an interesting question, "server" could mean several different things depending on the context. I interpreted it as "any entity outside the kernel the filesystem resides in", mainly because it's the simplest interpretation. Thanks, Miklos >> Signed-off-by: Miklos Szeredi >> Cc: Jan Harkes >> --- >> fs/coda/inode.c | 5 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/fs/coda/inode.c b/fs/coda/inode.c >> index 6058df380cc0..734672b2cbdc 100644 >> --- a/fs/coda/inode.c >> +++ b/fs/coda/inode.c >> @@ -255,7 +255,10 @@ static void coda_evict_inode(struct inode *inode) >> int coda_getattr(const struct path *path, struct kstat *stat, >> u32 request_mask, unsigned int flags) >> { >> - int err = coda_revalidate_inode(d_inode(path->dentry)); >> + int err = 0; >> + >> + if (!(flags & AT_STATX_DONT_SYNC)) >> + err = coda_revalidate_inode(d_inode(path->dentry)); >> if (!err) >> generic_fillattr(d_inode(path->dentry), stat); >> return err; >> -- >> 2.5.5 >> >>