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: [EMAIL PROTECTED]
> ..
> From: [EMAIL PROTECTED] (Anil B. Somayaji)
> Date: 19 Jan 1999 13:44:35 -0700
> Message-ID: <>
> ..
> * 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.
>
