On Sat, Sep 25, 2004 at 02:54:34PM +0900, Stephen J. Turnbull wrote:
> >>>>> "Troy" == Troy Benjegerdes <hozer_at_hozed.org> writes:
> 
>     >> Say what?  In terms of the file contents, disconnected
>     >> operation is just a set of additional restrictions on cache
>     >> semantics, no?  I would be surprised if a general facility like
>     >> cachefs will satisfy them out of the box.  It's possible, but
>     >> requires proof.  There's a pretty good chance that proof itself
>     >> will be on the order of difficulty of generalizing venus.
> 
>     Troy> The additional restrictions on cache semantics is keeping
>     Troy> track of what has changed that the server hasn't seen, and
>     Troy> resolving conflicts with the server.
> 
> And ensuring file integrity for disconnected operation.  In other
> words, venus needs to know everything that cachefs knows about what's
> cached.
>
> Furthermore, I can imagine applications that really want to assume
> that the whole file is available before they get to work, even though
> the data in Coda may be read-only for that application.  Currently we
> don't need an API for that.  With your scheme, we do, to account for
> situations where we go disconnected while a file is open for read.

Venus only needs to know what files it has completely cached. Partially
cached files could have either a per-volume or per-user switch to
determine whether than can be 'early-opened'. If we still want to block
on open, we can have another cache management process open the file and
start reading, and cachefs will turn around and start asking venus for
blocks. It can still hold off the original open() command to maintain
the old semantics.

This would provide a benefit of a file cache that can be shared among
multiple filesystems (afs, nfs, and coda), with no race conditions about 
the cache running out of space because some other user filled up the 
partition it was sharing.

> 
>     Troy> The hard part that requires proof is dealing with writes.
> 
> Writes are the hard part, yes, but they are not the only thing that
> requires proof.
> 
>     Troy> I can't think of very many situations I would actually
>     Troy> *want* to be able to write without requireing the whole file
>     Troy> be present,
> 
> Any "blind" append.  Files bigger than cache (think handhelds).  A
> database application might want to do it.  Journaling file systems
> already do it fairly generally in a certain sense.
> 
>     Troy> but there are a ton of situations where I want
>     Troy> to be able to read without waiting for the whole thing.
> 
> Sure.  You're impatient to read.  Other users/applications will be
> impatient to write.

yes, but I've seen more questions on the list about users impatient to
read, and I'd like to propose that using cachefs will provide a *first
step* that utilizes infrastructure that other people are debugging
instead of just us 5-10 active coda users ;)