Hi Jan,
> Coda 'solves' the page-aliasing issues by passing the kernel the same file
> descriptor as it is using itself to put the data into the container (cache)
> file. You could do the same and tell the kernel what the 'expected size' is,
> it can then block or trigger further fetches when that part of the file
> isn't available yet.
True. But how should I tell when a page isn't available yet, if I do as Coda
appears to do and directly use a file on another local filesystem (for Coda,
this doesn't matter since it maintains the entire file in its cache).
As for writing, surely Coda's solution is even worse? Since the pages in
question are "owned" by the backing cache file as far as the VM is concerned,
and all writes to a Coda file are ducted directly through to the backing cache
file, how do you (a) tell when the file has changed, and (b) tell which bits
of the file need to be sent back to the server? Do you send the entire file
back every time it gets changed? Do you keep a copy and "diff" the two?
> Basically when you open a file O_RDWR and write some data, and anyone else
> 'commits' an update to the file before you close the filehandle. Your client
> writes back the previously committed data, which it has proactively fetched,
> but with the local metadata (i.e. i_size).
This appears to be a flaw in the protocol, and it's going to be a problem, no
matter where the writes are done.
David