(Illustration by Gaich Muramatsu)
On Tue, Sep 21, 2004 at 01:44:27AM -0500, Brian Finney wrote: > are there any plans to do anything about coda blocking on open() The short answer, no. The only long term idea is to, possibly maybe, allow an open to return early (while we're still fetching the file contents) and to block the application whenever it tries to seek or read beyond the part of the file that has already been fetched. However, that is not all that trivial. We'd need to fork off a thread to perform the fetch, and have the kernel module intercept all reads and writes before we pass them to the underlying fs. I'm not even sure how to correcly deal with operations like mmap (hook into readpage/writepage?). > (such as mp3s and movies) it would be nice it coda could stream the > file, and maybe even jump around a little bit (doing a tail on a large > file) would be really nice. The problem with intercepting individual read and write operations is that it opens a window for some really nasty deadlocks. When the kernel tries to write out some dirty pages, this might require interaction with the userspace cache manager which in turn might have to be paged in from disk or swap, for which the kernel needs to clear some pages. This brings us back to the beginning, write out some dirty pages, but we're already doing that so we end up stuck. It also means that the kernel module needs to plug into the MM stuff instead of just the VFS, so it will make it harder to develop and maintain kernel modules for various kernels. Another problem is that we would need more metadata to keep track of which parts of a file are cached or not, streaming is relatively benign, because we only need a single offset to indicate progress. And we're already having scalability issues because there are limits to how much we can store in RVM. Furthermore, there are a couple of problems related to disconnected mode. When we're disconnected and only have parts of a file, should we really allow the user access even though we know we can't service all of his requests. Applications often expect and are reasonably well in handling errors from open, but many don't necessarily know how to deal with an unexpected error in read or write. Finally when we allow disconnected writes and there is a conflict, we end up with a partial copy of a file on the client with no means to reconstruct the complete file, because the copy on the server has already changed. So there is no way to compare the locally modified copy with the server's copy because we lost the common ancestor which we need to reconstruct a full copy of the local file. There is probably more, but these are some of the main problems I could come up with easily. JanReceived on 2004-09-23 00:07:39