On Wed, Sep 20, 2017 at 10:04 PM, Jan Harkes <jaharkes@xxxxxxxxxx> 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@xxxxxxxxxx>
>> Cc: Jan Harkes <jaharkes@xxxxxxxxxx>
>> ---
>> 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
>>
>>
