invalidating cache on chmod
Subsystems (2)
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.
Quoted 7 lines · J. Bruce Fields
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.
Signature · 5 lines
Trond Myklebust Linux NFS client maintainer, PrimaryData [email protected]