>>>>> " " == Michael Eisler <mre@Zambeel.com> writes:
> 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
This would be implemented with the last patch I proposed.
> - While the file is locked, do vypass the page cache for all
> I/O.
This is not possible given the current design of the Linux VFS. The
design is such that all reads/writes go through the page cache. I'm
not sure that it is possible to get round this without some major
changes in VFS philosophy. Hacks such as invalidating the cache after
each read/write would definitely give rise to races.
As far as I can see, the current use of the page cache should be safe
as long as applications respect the locking boundaries, and don't
expect consistency outside locked areas.
The exception here is mmap() for which no sane semantics can be found
unless the application explicitly unmaps and remaps after having
acquired the file lock.
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:13 EST