Messages in this thread | | | Date | Fri, 15 Sep 2000 09:19:32 -0700 | From | James Yarbrough <> | Subject | Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee |
| |
> This will always invalidate the page cache whenever we try to obtain > the lock, hence you are guaranteed that the cache will be reread after
> the lock was grabbed. > After unlocking however one needs no guarantees other than ensuring > that any modifications were committed while we held the lock, so we > flush the writebacks, drop the lock, and leave it at that.
What is done for bypassing the cache when the size of a file lock held by the reading/writing process is not a multiple of the caching granularity? Consider two different clients with processes sharing a file and locking 2k byte regions of the file and possibly updating these regions. Suppose that each system caches 4k byte blocks. If system A locks the first 2k of a block and system B locks the second 2k, the updates from one of the systems may be lost if these systems cache the writes. This is because each system will write back the 4k block it cached, not the 2k block that was locked.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |