Messages in this thread |  | | Subject | Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee | From | Trond Myklebust <> | Date | 18 Sep 2000 20:01:25 +0200 |
| |
>>>>> " " == Michael Eisler <mre@Zambeel.com> writes:
>> I'm not clear on why you want to enforce page alignedness >> though? As long as writes respect the lock boundaries (and not >> page boundaries) why would use of a page cache change matters?
> For the reason that was pointed earlier by someone else as to > why your fix in adequate. Since the I/O is page-based, if the > locks are not, then two threads on two different clients will > step over each other's locked regions.
No they don't.
As I've repeatedly stated, our cache does not require us to respect page boundaries when writing. We do make sure that all writes pending on the entire file are flushed to disk before we lock/unlock a region. If somebody has held a lock on 2 bytes lying across a page boundary, and has only written within that 2 byte region, a write is sent for 2 bytes. There is no difference here between cached and uncached operation. The only difference is that we trust the lock to prevent other machines writing within the locked region.
When reading, we have now (assuming the patch I just sent in to Linus was accepted) ensured that all pages that were cached prior to grabbing the lock are thrown out. Any new access to that file will cause the relevant pages to be reread from the server. Even if we're extending a lock, within a page boundary or locking a new portion of the file then all existing writes are flushed to disk first, and the entire page cache is invalidated. Again any access to the newly locked region will result in a reread from the server.
Cheers, Trond - 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/
|  |