[Linux-cachefs] Finding fscache contents for a file

[David Howells]

John Groves <John at groves.net> wrote:

> That begs the question as to how I can get the latest possible fscache code
> into an EL5 kernel.

It's not something we can do.  The kABI is really annoying in that regard.

> Hole punching would be ideal, but I understand the limitation.  Yes, I have
> a cookie.
> 
> Currently, if a DLM lock is revoked, I just blow away the whole file in the
> fscache -- at least that's what I think I'm doing.  I call a function
> derived from nfs_fscache_disable_cookie(), which appears to clean up the
> page cache and then call fscache_relinquish_cookie().

That sounds about right.  You tell fscache_relinquish_cookie() to retire the
cookie, then you go and get a new one.

> A bit map would be cool.  An extent list would be OK too.

A bitmap would be easier since it is constant size.  An extent list would be
of uncertain size.  The worst case would be where pages are alternately
present and absent.

> Or just an ability to ask fscache whether a given page (or extent) is in the
> disk cache...

That's certainly possible.

> I'm more concerned about the converse: proving that what should have been
> removed from the fscache has been duly removed.

That's more tricky...  You have to know to expect there to be nothing in the
cache that you can reuse.  You might be able to use the auxiliary data for
that.

> We noted early on that there was a big difference between the fscache code
> here and in "current" kernels, and that grafting the latest fscache code
> into the 2.6.18 tree didn't look trivial...is there a way to get a "modern"
> fscache patched into a more or less EL5 kernel?

Hmmm...  Tricky...  Well, the fscache and cachefiles I/O parts are reasonably
straightforward.  The problem is the security stuff.  What's in RHEL5 doesn't
go anywhere near far enough.  If you are willing to ignore the security
issues, then it's less of a problem.

> I did some more experiments, and the missing pages seem not to occur if I
> take a lunch break after reading them into the page cache (and writing to
> fscache), and then blow away the page cache after lunch.

That would give cachefiles a chance to write out the pending pages.

> Doh...my kernel doesn't even have a /proc/fs/fscache.  I'm pretty far
> downlevel, I guess. Do you know what version of fscache the /proc entry
> appeared in?

Some time after RHEL-5 was cut.  I don't remember exactly what.

> > Can you show me your releasepage() method?
> 
> 
> It's attached at the bottom of this message.  Should it be looking at the
> fscache bits?

Note that your ll_releasepage() always tells the caller it may eat the page
afterwards, regardless of whether ll_removepage() thinks this is true or not.

Now, I don't fully understand your code since I don't know what
__ll_put_llap() does, but if fscache is writing a page, you should wait for
PG_fscache_write to be cleared if gfm_mask & __GFP_WAIT, otherwise you should
return false.  If PG_fscache_write is clear or becomes clear, then you should
uncache the page.

David