Perhaps some sort of watermark could be set for what is acceptable to
cache as a whole file and what is not?
In other completely different news, I tried compiling coda on my Alpha and
I got laughed at by my compiler...
The first minor choke was in lib-src/lwp.c at line 552:
if ((int) stackptr == -1)
stackptr is originally typed as (char *)...in Alpha-land, pointers are 8
bytes and sizeof(void *) == sizeof(long), not sizeof(int)...
What kind of evil voodoo is this and what's the proper way to fix it?
Jason
On Wed, 20 Jan 1999, Robert Watson wrote:
> On Wed, 20 Jan 1999, Peter J. Braam wrote:
>
> > > AFS deals with this by 'chunking' -- that is, it demand-loads portions of
> > > files into the cache as they are needed; I believe it also uses an
> > > agressive read-ahead policy. The net result is more efficient use of the
> > > cache for partial file reads or writes, especially for mammoth files.
> >
> > I just sent a message about this.
> >
> > > However, that raises consistency issues: currently the resolution of
> > > conflicts between file versions is that of entire file system objects
> > > (files or directories). Dealing with fine-grained inconsistency severely
> > > complicates the repair process, I would guess; it is not even clear if the
> > > client would have access to the whole file version it is attempting to
> > > integrate. For disconnected operation anyway, it seems like transferring
> > > the whole file is more useful, as the chances are high that if you access
> > > a bit of the file, you will access all of it (loading it into emacs,
> > > writing it out, etc).
> >
> > Whoops, this is a good point. However, the conflict resolution mechanisms
> > themselves would use the chunk fetching code, so it need not really be a
> > problem.
>
> The problem situation I was thinking of was this: Client1 is connected,
> and retrieves the middle chunk of a file. A write is made to the middle
> chunk, but before it can be written back, Client1 goes disconnected. we
> now have a pending write on the middle chunk of a file, but only the
> middle chunk is on Client1. Client2 now bops up and proceeds to modify
> the file in some manner, and succeeds. Client1 now reconnects. A
> Client-Server conflict has arisen and must be resolved for the change to
> be reintegrated. However, because only a small part of the entire file is
> available on Client1, the resolution process may now be more difficult.
> Consider, for example, the case where it is an MS Word file. An
> application-specific resolver is required, but it doesn't have access to
> the two complete versions of the file, so it may not even have access to
> the old file header :(. The whole-file-in-cache is a simplification for
> version control that I think really does make life easier.
>
> On the other hand, chunking would definitely improve performance
> (especially perceived performance during a more or the like--the latency
> to the first available data is much lower). Maybe this is an appropriate
> application for the 'client class' behavior I suggest below, and that we
> both seem to agree is a large project and should wait :(.
>
> > > > I was really hoping to have home directories mounted over coda, with inbox
> > > > being stored right in the accounts, (and also large procmail filtered
> > > > mailing-list archived mail folders) but that wont be feasible until at
> > > > least write-back caching is available in a connected state.
> > > >
> > > > I just got coda running recently, but the initial excitement has faded
> > > > somewhat after discovering the above.. :(
> > >
> > > My suspicion is that the arrangement you describe will suffer from Coda's
> > > weak consistency model: if multiple clients are using write-back caching,
> > > then conflicts can occur.
> >
> > Write back caching wil have the same semantics as connected Coda.
> > If another client comes along, then the one holding the write back token
> > will have to reintegrate first.
> >
> > Conflicts in Coda arise as easily in connected mode as in AFS you would
> > overwrite data (last close wins in AFS). The problem with receiving email
> > in Coda is locking to avoid conflicts. I don't know how AFS does this,
> > but with NFS it is certainly possible to ruin your mailbox easily.
>
> Token-like behavior for file systems is clearly very nice, and would
> improve consistency. However, this is a departure from the traditional
> Coda consistency model. With replicated servers, how will tokens be
> allocated, and by which server(s)?
>
> In Coda, conflicts are more easily come upon than AFS-last-close behavior
> because of replication. Having the 'AFS-class client' that uses
> last-close and timestamps to manage conflicts might result in unexpected
> but at least non-interactive behavior.
>
> > It's a good puzzle to see if Coda's connected semantics allow for the
> > atomic creation of a lock file. Perhaps that is just possible. On the
> > other hand, I don't really have much more faith in AFS or NFS without lock
> > daemons when it comes to my mail.
>
> I would guess that Coda does not allow atomic creation on a replicated
> volume, only on an unreplicated one. Even then, only Venus will know
> whether it was atomic and successful; if the client is disconnected, then
> the userland mail process only sees the lock file creation succeed, and
> doesn't know it has been logged. Similarly, you might have problems with
> lock files being left around: client is connected, creates lock file, and
> then goes disconnected. This is a lock like that nasty netscape problem
> with netscape crashing and leaving lock files all over the place, only in
> this case the disconnected mail client still thinks it has an atomic lock
> :O.
>
> As such, a disconnected system really needs to support lock preemption,
> possibly notification, and certainly verification that a lock is still
> valid. Perhaps an optional distributed lock manager could be used with
> Coda (presumably replicated with strong consistency in the style of Ubiq
> or using a multi-party lock algorithm). Disconnected operation still
> introduces incomfortable situations, but at least connected clients could
> guarantee locks. My suspicion is, however, that when there are already
> specific multi-user locking semantics for a specific application, that
> application should be served by its own replication mechanism and not by a
> file system with weak consistency. So replicated IMAP servers might be a
> better solution, with IMAP's disconnected operation and reintegration
> techniques. Or a mail reader that takes advantage of Coda as a message
> store with weak sementics.
>
> > > This is not to suggest that Coda is not useful in such an environment;
> > > it's real benefits come in the case of mobile computing. It might be
> > > interesting to introduce the concept of different 'classes' of client:
> > > that is, the semantics and consistency enforced for a particular client
> > > might depend on the role it was expected to play.
> >
> > Yup, unfortunately, that's a rather major project probably.
>
> It sounds like it. Ideally I see something like this:
>
> venus -consistency strong
> venus -consistency afs
> venus -consistency codamobile
> venus -consistency slush
>
> In each case, the strongest consistency available would be used, but the
> fallback case where it wasn't would be different. That is, if you started
> venus with codamobile, when connected you'd get AFS or strong consistency,
> but when disconnected you'd get logging and reintegration. With AFS
> consistency at startup, you'd get strong or AFS connected, and when
> disconnected either everything hangs or obeys last-write based on
> timestamps or something. With strong, you'd get strong or hangs.
>
> Robert N Watson
>
> [EMAIL PROTECTED] http://www.watson.org/~robert/
> PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C
>
> Carnegie Mellon University http://www.cmu.edu/
> TIS Labs at Network Associates, Inc. http://www.tis.com/
> SafePort Network Services http://www.safeport.com/
>
