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

From: Andrew Morton
Date: Wed Nov 16 2005 - 06:56:46 EST

David Howells <dhowells@xxxxxxxxxx> wrote:
> 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:-)

Maybe on the fourth or fifth time it'll occur you to put it into the

> ...
> 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
> cache.
> (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.

None of that appears to be relevant.

A blockdev is just a big, fixed-sized file. Why cannot it be backed by a
big, fixed-sized file?


OK, it's doing submit_bio() directly.

> 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:
> (*) O_DIRECT
> (*) 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.

I'd have thought that a decent intermediate step would be
cache-on-single-file using a_ops.direct_IO, as you're implying above. Then
all the direct-to-blockdev code can go away. It'll take some tweaking of
the core direct-io code, but nothing terribly serious.

> Are you willing to at least carry the FS-Cache core and the AFS usage of it?

fs-cache won't do anything without a backing store such as cachefs will it?

Those names are rather confusing, btw.

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