From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Brian L. Stuart" <blstuart@bellsouth.net>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] QTCTL?
Date: Thu,  1 Nov 2007 04:21:03 +0000
Message-Id: <110120070421.28207.4729542F0007C92100006E2F22228869349B0A02D2089B9A019C04040A0DBF9B9D0E9A9B9C040D@att.net>
Topicbox-Message-UUID: e29dfb9e-ead2-11e9-9d60-3106f5b1d025

> If the file is "decent", the cache must still check out
> that the file is up to date. It might not do so all the times
> (as we do, to trade for performance, as you say). That means
> that the cache would get further file data as soon as it sees
> a new qid.vers for the file. And tail -f would still work.

This is really starting to sound familiar.  A couple years ago,
I played around with a caching file system for laptops.  They
always bugged me, because they didn't play nice in a network with
a file server.  So it's meant to operate the same way whether
connected to the file server or not.  On reads, it checks the
file as described above, if connected to the file server.  When
connected, it implements a write-through cache, but records
writes when not connected.  When it connects again, it plays
back the writes, after a little optimizing.  And if the file
has already changed while we were disconnected, I flag it as
a conflict and invoke the powers of a human.

My first playing was in Plan 9, and then with fuse on Linux.
I've been using that version as the primary file system
for my home directory, caching a file server at home and
one at work.  It's not really ready for prime time, but it's
weaknesses are ones that I can live with at the moment.
So I haven't touched it in a while.

But to the question at hand, I never really thought in terms
of it being used for files that didn't connect to persistent
storage.  I always figured the persistent and the non-persistent
would be mostly in different directory trees, so I just ignored
the problem.  Another simplifying short cut was to not try
to implement the network import in it.  It just presents a
cache of one directory tree at another name.  So the authoritative
version is accessed through a normal remote mount.  It makes
some things simpler, but it also keeps it from seeing the
protocol traffic with the server.  In this scenario, it seems
the place to keep a cachability flag would be in the file
metadata, rather than in the protocol itself.  But then again,
my motivation wasn't to improve latency tolerance.

Of course, Russ is right that we can't be sure of coherence
without a way for the server to invalidate the cache of a
file.  But in my case, that wouldn't be available while
disconnected, and the way I use it, conflicts are more
likely when disconnected than while connected.  So I decided
to detect the conflict, rather than prevent it.  That meant
I didn't have to make any changes to the server side and
I could take the shortcut to just map one tree to another.

So this might not add anything to the discussion, but
it'd be nice to account for a wide range of caching
applications.

BLS