Re: [PATCH 0/12] FS-Cache: Generic filesystem caching facility

From: David Howells
Date: Wed Nov 16 2005 - 06:26:46 EST

Andrew Morton <akpm@xxxxxxxx> wrote:

> > What I'm trying to do is actually fairly simple in concept:
> >
> > (1) Have a metadata inode (imeta) that covers the block device.
> >
> Can you remind me again why it requires a blockdev rather than a regular file?

That's the third time you've asked:-) You should be able to find the previous
conversations in LKML archives.

I presume directing you to go and look at the CacheFS documentation in patch
12/12 would be out of the question? Particularly the section entitled "Why a
block device? Why not a bunch of files?"...

Look also at Documentation/filesystem/caching/fscache.txt provided by patch
9/12 for the constraints I've set, in particular:

(1) It must be practical to operate without a cache.

(2) The size of any accessible file must not be limited to the size of the

(3) The combined size of all opened files (this includes mapped libraries)
must not be limited to the size of the cache.

(4) The user should not be forced to download an entire file just to do a
one-off access of a small portion of it (such as might be done with the
"file" program).

To which I wish to add:

(5) The netfs pages must remain owned by the netfs, so that there is no
difference between the netfs operating with a cache and it operating
without a cache. This means I/O must be done to/from the netfs pages
directly from/to the cache.

I have a start of a cache-on-files facility (called, most imaginatively,
CacheFiles) which works as another backend to FS-Cache. Of the underlying
filesystem, it requires:


(*) Reads and writes on arbitrary kernel pages

(*) Reads on holes must return short or ENODATA. This requires an extra
O_XXXX flag to be supplied when opening a file or the struct file or
inode to be flagged appropriately.

(*) The ability to issue FS operations such as rename, open, setxattr, mkdir
from kernel space.

This facility isn't well advanced yet, and will initially only be available on
EXT2/3. It will also require a userspace component to clean up dead nodes.

Are you willing to at least carry the FS-Cache core and the AFS usage of it?
They haven't changed for a long time, and hopefully shouldn't need to:

(*) Subject: [PATCH 8/12] FS-Cache: Add generic filesystem cache core module
Patch: fscache-core-2614mm2.diff

(*) Subject: [PATCH 9/12] FS-Cache: Add documentation for FS-Cache and its interfaces
Patch: fscache-docs-2614mm2.diff

(*) Subject: [PATCH 10/12] FS-Cache: Make kAFS use FS-Cache
Patch: fscache-afs-2614mm2.diff

Once I've updated them for Linus's comments, that is...

All the other patches have to do with CacheFS.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at