It's not very complicated to cache chunks of files.  You have to maintain
a bitmap of dirty chunks you hold and I would proceed as follows:

When a file is opened it is not fetched, but an empty file is created of
the correct length, i.e. it is sparse.  This means that bmap returns 0 on
all of the blocks.  If something needs to be read or written, one first
does bmap: if it returns 0 the cache manager (venus) fetches the chunk of
the file and then proceeds.  If bmap doesn't return 0 then the block is
there and one can proceed. 

This is not really high on our list of priorities to do, but it's
definitely possible.  The problem I see with using NFS for this is that it
isn't secure at all, and that failure modes are hard to handle. Then,
maybe that doesn't always matter.

- Peter -



On Wed, 20 Jan 1999, Bruce Janson wrote:

>     ..
>     To: codalist_at_TELEMANN.coda.cs.cmu.edu
>     ..
>     From: soma_at_cs.unm.edu (Anil B. Somayaji)
>     Date: 19 Jan 1999 13:44:35 -0700
>     Message-ID: <ut24spnq9fw.fsf_at_lydia.adaptive.net>
>     ..
>      * Does a client's cache have to be big enough to hold any single
>        file?  Or does it have to be big enough to hold a whole directory?
>        We definitely had problems when we tried copying a 23M file into
>        coda when the client only was set up with a 20M cache.
>     ..
> 
> Anil and Fellow Codaphiles,
>     At the core of this question is an important design(?) limitation of Coda.  
> By insisting that all open files be cached (and so read and written) locally,
> the total size of all open files must be less than the size of the local cache.
> In practice this is not too critical a limitation.  At least a part of Coda's
> target is the realm of mobile, disconnected computing.  For mobile users this
> often means a single-user laptop which I would expect would open only a small
> number of small files at once.  But in the (nearly) orthogonal realm of
> large-scale reliable computing (redundancy, higher performance) this limitation
> is more of a problem.
>     In fact, the current Coda implementation makes things worse than they need
> be.  A cached file can grow to consume all free space on the local cache.
> At this point the kernel could request that Venus (i.e. the cache manager) free
> up cache space if possible, presumably by removing cached but unopened (and
> unhoarded?) files.  At present the kernel code and kernel<->Venus upcall that
> would be required to do this do not exist.  Venus also must be ready to perform
> cache `garbage collection' when it tries to install a file into the cache
> during that file's first open.  I am not sure whether Venus does this at
> present (the Venus source code was less than scrutible on this point :-)).
>     Peter [Braam], at present I expect that in our (ongoing, nefarious, ab)use
> of the kernel<->Venus protocol we will move towards a hybrid Coda/Potemkin/NFS 
> system which will give us finer grained (i.e. block-level) caching as well as
> neatly side-step the above local caching limits.  Nevertheless, I would be
> interested to hear what, if any, plans the Coda development team has with
> regard to these issues.
> 
> Regards,
> bruce.
>