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.

Jan