David Howells <[email protected]> wrote:
>
> Andrew Morton <[email protected]> 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
changelog.
> ...
> 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?
<looks>
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
