As of (a backport of) 3a1556e8662 "NFSv2/v3: Simulate the change
attribute" we have a user complaining about chmod on the client
invalidating data caches. (They have some sort of pipeline running on
the client where output from one stage is has ownership and permissions,
but not data, change before being used as input to the next.)
Looks like that's expected?
--b.
On Wed, Jul 16, 2014 at 12:38 PM, J. Bruce Fields <[email protected]> wrote:
> As of (a backport of) 3a1556e8662 "NFSv2/v3: Simulate the change
> attribute" we have a user complaining about chmod on the client
> invalidating data caches. (They have some sort of pipeline running on
> the client where output from one stage is has ownership and permissions,
> but not data, change before being used as input to the next.)
>
> Looks like that's expected?
Yes, that's expected. There is a tradeoff here: we could either use
the ctime, in which case there is the problem of false negative cache
revalidations (in cases such as the above), or we could use the mtime,
which has a problem of false positive cache revalidations (after an
application deliberately sets the mtime value).
The choice fell on ctime because that's what was being used for NFSv4
and, because false positive revalidations can lead to data corruption,
whereas false negatives do not.
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
[email protected]