[lkml]   [2000]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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?
two different clients with processes sharing a file and locking 2k byte
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
the second 2k, the updates from one of the systems may be lost if these
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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.038 / U:1.392 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site