>>>>> " " == 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/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:18 EST