> >>>>> " " == James Yarbrough <jmy@engr.sgi.com> writes:
>
> > 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.
>
> Under Linux writebacks have byte-sized granularity. If a page has been
> partially dirtied, we save that information, and only write back the
> dirty areas. As long as each system has restricted its updates to
> within the 2k block that it has locked, there should be no conflict.
>
> If however one system has been writing over the full 4k block, then
> there will indeed be a race.
Using a page cache when locking is turned on is tricky at best. The
only working optimizations I know of in this area are allowing
the use of page cache when the entire file is locked.
My two cents ...
Focus on correctness and do the expedient thing
first, which is:
- The first time a file is locked, flush dirty pages
to the server, and then invalidate the page cache
- While the file is locked, do vypass the page cache for all I/O.
Once that works, the gaping wound in the Linux NFS/NLM client will be
closed. This will give you the breathing room to experiment with
something that works more optimally (yet still correctly) in some conditions.
E.g., one possible optimization is to allow page I/O as long as the
locks are page aligned or whole file aligned.
-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 : Fri Sep 15 2000 - 21:00:26 EST