is cache-only-prefixes an nnpfs limitation?

[Tomas Olsson]

Adam Megacz <megacz at cs.berkeley.edu> writes:

> Ok.  Is it currently possible for the userspace to know when the
> kernel has read the block, so it can evict it immediately?
>
Not at the moment, but we should add such a pioctl. For the time being
there's the "flush file" pioctl.

> Hrm, why does linking to arlad enable this?  Does arlad offer some
> extra undocumented interface to nnpfs?
>
One could implement a wrapper around open() that calls the
{Fetch,Store}Data rpc directly, but uses /afs for directory operations.  No
nnpfs involved for the I/O, just pass your buffer to rx.

> So currently nnpfs makes a call to userspace every time it needs to
> find a cached block?  I thought the thing that made this all work with
> acceptable performance was that the nnpfs kernel module already
> maintained such a cache (though very small)...
> 
No, there is a cache, and we rarely need to call arlad for repeat reads.

Currently arlad takes care of all cache replacement things, on a node
level. The problem is that it's really nnpfs that gets all the syscalls and
knows what nodes are used, so arlad just somes up with nodes that it
*thinks* are not recently used, and says "can these be dropped?".

For blocks (especially when we start talking about files larger than your
cache) things get more complicated.  So we figured it's time for nnpfs to
use the information available to it, and assume responsibility for the LRU.
But then there's the readahead that arlad has been responsible for, and
which nnpfs traditionally knows nothing about.  And from the nnpfs side
there are writes/appends that consume cache space without arlad being
informed.

/t