>> > > quick question: Is there any support for write caching on NFS{,v4}
>yet?
>> > No, not yet.
>>
>> Is there work being done on it, perhaps even an ETA?
>
>Not at the moment. It's not particularly difficult to implement simply.
>The problem is one of cache coherency. If you make a write to the NFS
>server, how do you know that your write hasn't hidden someone else's write >that was performed immediately before? With NFS2/3 the only consistency >data you have is the mtime, ctime and filesize. NFS4 adds further > >information, but I'm not sure how useful it actually is.
If two NFS clients open the same file for write access, don't they need to use file locking or byte-range locking to avoid stepping on each other?
And the corollary: if two NFS clients open the same file for write access and don't use file or byte-range locking, don't they deserve what they get?
Also, if a pNFS client has been has been delegated responsibility for opens for a file, won't that delegation be revoked if another pNFS client tries to open the same file for writing?
I agree, cache coherency in pNFS is a big headache, but hopefully section 10 (Client-Side Caching) of RFC 5661 makes the pain explicit enough to deal with.
In particular, the pNFS server is supposed to maintain a "changed" attribute for every file. This would be useful for revalidating after doing an open. This whole thing looks rife for races, though.
-=# Paul Gilliam #=-
-=# Paul Gilliam #=-
--
Linux-cachefs mailing list
Linux-cachefs@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cachefs
