Daniel Phillips [off-list ref] wrote:

quoted

I know you want to ruthlessly trim out anything that isn't used, but please
be patient:-)

Are you sure CacheFS is even the right way to do client-side caching?

It's just one way. See the attached document for how it works.

What is wrong with handling the backing store directly in your network
filesystem?

What do you mean by "handle the backing store"? Note that the system I'm
proposing involves directly moving data between netfs pages and the cache. I'm
trying very hard to avoid copying the data any more than I have to.

You have to hack your filesystem to use CacheFS anyway, so why not write
some library functions to handle the backing store mapping and turn the hack
into a few library calls instead?

FS-Cache is just that. CacheFS is one of a number of proposed backends.

I just don't see how turning this functionality into a filesystem is the
right abstraction.  What actual advantage is there?  I noticed somebody out
there on the web waxing poetic about how the administrator can look into the
cache, see what is cached, and even delete some of it.  That just makes me
cringe.

Well... With CacheFS you can't do that; not now, at least.

Using a block device has the very great advantage that it's a lot easier to
provide guarantees about service quality. Reading an NFS file through CacheFS
on a blockdev seems to be somewhat faster than reading the same file from
EXT2. I'm not sure why, but I'm sure Stephen and others will be very
interested if I find out.

The downside of using a block device is that you have to have one available,
and it can't easily be used for something else. Actually, this last isn't
entirely true: CacheFS is a filesystem after all...

Actually, given that CacheFS is a filesystem, that makes the userspace UI for
using it very simple...

Besides, who says CacheFS will be the only back end? CacheFiles is coming too,
but CacheFiles is, in many ways, a lot harder as I have to work through an
existing filesystem, using existing access functions. Not only that, but
CacheFiles can't provide a guarantee of minimum space and can't provide
reservations. CacheFiles has to be able to use O_DIRECT (which I have a patch
for), but has to be able to detect holes in the backing file.

What ever you do, do not forget the following hard requirements:

 (1) It must be trivially possible run without a cache.

 (2) It must be possible to access a file that's larger than the maximum size
     of the cache.

 (3) It must be possible to simultaneously access a set of files that are
     larger than the maximum size of the cache.

 (4) It mustn't take hours to open a huge file, just so you can access one
     block.

 (5) The cache must be able to survive power failure, and be recovered into a
     known state.

 (6) It must be possible to ignore I/O errors on the cache.

 (7) There mustn't be too much change to the netfs. FS-Cache doesn't really
     have that much of an impact on any filesystem that wishes to use it.

Note that if you're thinking of using i_host on the netfs inode to point at
the cache inode, and downloading the entire file on iget(), possibly in
userspace, then forget it: that violates (2), (3), (4) and (6) at the very
least.

David