Hi Trond,
Commit ca0daa2 ("NFS: Cache aggressively when file is open for writing")
removed the inode revalidation from do_setlk(). Why was that necessary?
If just that part of the commit is added back in, the client still seems
to be able to cope with out-of-order write replies.
Currently the client invalidates the data cache whenever it takes a lock
and that causes performance problems for some workloads... if a client
wants to re-read portions of a file, and no other client has modified
that file, then why should the reads go out on the wire just because
locking is being used?
-Scott
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
