Re: [nfsv4] follow-up of xattr discussion

"nfsv4" <nfsv4-bounces@ietf.org> wrote on 07/23/2015 11:45:47 AM:

> From: "J. Bruce Fields" <bfields@fieldses.org>
> To: David Noveck <davenoveck@gmail.com>
> Cc: Christoph Hellwig <hch@lst.de>, "nfsv4@ietf.org" <nfsv4@ietf.org>
> Date: 07/23/2015 11:46 AM
> Subject: Re: [nfsv4] follow-up of xattr discussion
> Sent by: "nfsv4" <nfsv4-bounces@ietf.org>
> 
> On Thu, Jul 23, 2015 at 01:15:22PM -0400, David Noveck wrote:
> > which sound to me like such uses for not allowed.  I'll be reviewing
> > this document in a bit and will propose some toughening up of the
> > language.
> 
> One of the practical difference is the caching.  A lot of the
> filesystem-specific attributes look incompatible with client caching.
> 
> Looking at the "caching" section: it does say clients may cache reads,
> and that the change attribute can be depended on to validate that cache,
> but:
> 
>    https://tools.ietf.org/html/draft-naik-nfsv4-xattrs-02#section-6.2.2
> 
>    Such caching is write through in that modification to xattrs is
>    always done by means of requests to the server and should not be
>    only done locally. Due to the relative infrequency of xattr
>    updates, it is suggested that all changes be propagated
>    synchronously. The client MUST NOT maintain a cache of modified
>    xattrs.
> 
> What's the rationale for that MUST NOT?

Same as the one for all other attributes (except size, time_modify, 
change): see https://tools.ietf.org/html/rfc5661#section-10.6

Manoj.

> 
> --b.
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
> 