thank you very much for the answer

that helps clear allot of things up in my mind. 

I wouldn't expect coda to allow any kind of a write operation on a
file that had not been loaded completely into the cache, to do so
would seem to be just plain unreliable and asking for trouble. 
However it would seem like there would be little if any harm in
allowing read only operations on parts of a file on demand, e.x. while
loading the file into the cache also allowing a prog to read as the
data comes in (such as an mp3 player) and then if the file fails to
load fully into the cache reporting an eof to the prog and removing
the partial file from the cache to avoid any reintegration issues or
if a program wants a particular piece of a file (such as tail or just
the mp3 tags) then going ahead and getting that piece while loading
the whole file into the cache in the back ground and once again if the
whole file cannot be fetched purging any parts of it from the cache.

obviously this would require progs that only want to read parts of a
file to only open the files for read and not read write, although I
have no clue if that information even makes it to the vfs.

As I have a very limited understanding of the exact nature of the
connection between the kernel and the vfs I may be completely off base
here as far as what is possible.

thanks for any information and the opportunity to bounce my ideas of the list

On Thu, 23 Sep 2004 00:04:26 -0400, Jan Harkes <jaharkes_at_cs.cmu.edu> wrote:
> 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
> 
>