[Linux-cachefs] Re: [PATCH] [Request for inclusion] Filesystem in Userspace

[David Howells]

Miklos Szeredi <miklos at szeredi.hu> wrote:
> > Check fscache (or cachefs), right now it has the 'problem' that it
> > considers all cached pages as purgeable, but David Howell's did express
> > some interest in adding the ability to pin pages until the fs has
> > written back the data or at least he will probably consider accepting
> > patches to that extent.
> 
> OK.  It's not clear to me who is the 'owner' of a page.  Is it the
> page cache or cachefs?  So what exectly happens when I update a page
> in fscache?  Is it copied to an cachefs page and then later written
> back to disk, or is it immediately sent to disk?

That depends on what you mean by a page. The blocks in the on-disk cache are
owned by cachefs because they're on the blockdev. That much, however, is
transparent to the netfs. It asks cachefs (through fscache) to cache a page,
and cachefs either complies or refuses.

Actual data pages in the pagecache are owned by the netfs. The netfs asks
fscache to load data from a cache into a page the netfs owns. If there wasn't
a page in the cache, or the netfs wants to update the cache, the netfs asks
fscache to store the data in the cache.

How the store is actually done is entirely up to the cache backend. It can
copy it into a separate page if it wants, or write it directly to disc (as
cachefs does). The only requirement is that once a write-to-cache has been
issued, the page mustn't go away until the callback function is invoked.

As it happens, if CacheFS is the backend, then when you ask for a page to be
written to disc CacheFS will flush the journal if the block on the blockdev
was recycled after holding metadata, and then set up a BIO to write the
netfs's page's contents directly to the blockdev. This may or may not go
directly to disc, depending on what the blockdev actually is, but you needn't
worry about that.

CacheFS will store its own metadata pages in the pagecache, but they're
irrelevant to the netfs.

However, that said, you shouldn't need to worry about most of that. As long as
you are aware that a page may be accessed at any time by the cache backend
between calling fscache_write_page() and the callback being invoked, then you
should be okay.

> > Effectively both clean and dirty pages would get backed on disk by
> > fscache, this might be advantageous especially if FUSE has to pull the
> > data off of some slow medium or from the network. 
> 
> That sounds good, though I think it would be better if caching could
> be made optional.  Many userspace filesystems are not network
> filesystems, and often recreating the data is cheaper than reading
> back from a disk cache. 

Whether caching is used or not is entirely at the convenience of the netfs;
oh, and the presence of at least one cache. FS-Cache will do its best to make
sure things still work if there isn't a cache.

> > If the dirty pages can
> > get pinned, then a write would work as follows,
> > 
> >     writepage
> > 	update (and pin) page in the fscache
> > 	queue (async) write request to userspace
> > 
> > Now as far as the kernel is concerned once writepage returns the page is
> > clean and can be dropped. Userspace can then use a downcall to pull the
> > page out of the fscache and unpin it. I don't know if fscache/cachefs
> > has a filesystem like interface which would allow access to the page
> > directly with open/seek/read operations without going back through the
> > FUSE kernel module.
> 
> It sounds to me cleaner if cached data is always accessed through
> FUSE, so I don't think such an interface is neccessary, nor that it
> would improve performance.

It sounds like I've missed part of this conversation, but you can always write
to FS-Cache and downcall to userspace simultaneously.

I can add an interface to allow userspace to access the caches directly if
need be; something you'll probably want if you want to be able to sync
unwritten data stored in the cache during off-line operation.

David