> I've been thinking about how to make coda work with cachefs, and I'm not
> sure how the fs-cache frontend will change things. For example, how do
> you deal with holes with a file-based cached in /var/cache?
bmap. Yuck.
> If there is pinning support, I'm not sure there is a need for a writeback
> journal.
The way I'm thinking about it is:
(1) Upon open(), Codafs acquires a cache file, pre-pinned and with X amount
of space reserved in the cache.
(2) Codafs calls the Coda userspace to fill the cache. It marks the cache
cookie with a "pre-loading cache" flag and sleeps on it. This mark is
also retained on disc in the cache.
(3) Coda userspace copies the data from the server into that cache file and
then clears the "pre-loading cache" flag, waking up anyone sleeping on
it. The mark is cleared on disc to say that the file is ready to go.
If an error occurs then the cache file is retired and recycled.
If there's a system crash and the file is part initialised, the file will
be scragged by the cache journal replayer and never seen again.
When the user writes to a file:
(1) Codafs makes a note in the writeback journal to say that this file now
contains X bytes of dirty data at position Y in the file, written by
person Z. The dirty data is stored in the cache.
(2) When the file is written to the server, it can be written straight from
the cache, and then the writeback journal mark can be cleared.
(3) If there's a crash, coda's recovery tools can note the mark in the
wb-journal and decide whether to keep the dirty data as is, complete with
outstanding journal mark; clear the mark; write the data back; or nuke
the cache file.
This will take some work in FS-Cache and CacheFS, but I don't think it's that
hard.
David
