> >>>>> " " == 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.
What if someone has written to multiple, non-contiguous regions of a page?
> 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.
So, assume a page is 4096 bytes long, and there are 2048 processes that each
have write locked the even numbered bytes of the first page of a file. Once
all the locks have been acquired, the page has been flushed to disk.
Now we have a clean page. Each process then writes only one byte region that
it has locked.
Now they unlock the region.
What happens?
(btw, on another nfs client, 2048 processes have locked the odd number bytes
of the first page of the same file).
If you claim that first client doesn't overwrite the updates from the
2nd client, then I'll shut up.
-mre
-
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