| Message ID | 1505896805-12055-4-git-send-email-mszeredi@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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. Jan > Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> > Cc: Jan Harkes <jaharkes@cs.cmu.edu> > --- > 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 > >
On Wed, Sep 20, 2017 at 10:04 PM, Jan Harkes <jaharkes@cs.cmu.edu> 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 <mszeredi@redhat.com> >> Cc: Jan Harkes <jaharkes@cs.cmu.edu> >> --- >> 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 >> >>
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;
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. Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> Cc: Jan Harkes <jaharkes@cs.cmu.edu> --- fs/coda/inode.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)