is cache-only-prefixes an nnpfs limitation?

[Adam Megacz]

Tomas Olsson <tol at stacken.kth.se> writes:
> assumed to be a power of 2.  For some reason I'm also assuming a 1:1
> mapping between (fid, offset) and cache "block" file.

That shouldn't be a problem in the short term, and actually this is
the correct approach in the long term if the underlying filesystem
handles small files properly (ie rieserfs).  But for people using
ext3/vfat/ntfs to support the cache this may not scale.  Not a
near-term concern though.


>>   - If it is known that a remote file will only be read once, is it
>>     possible to avoid writing it to the localfs disk?

> Later.

Ok.  Is it currently possible for the userspace to know when the
kernel has read the block, so it can evict it immediately?


> The HPC folks are almost ready to kill for this (and cacheless writes).
> Right now they'll have to resort to linking against arlad to do it.

Hrm, why does linking to arlad enable this?  Does arlad offer some
extra undocumented interface to nnpfs?


> The install messages aren't connected to the requests, there's a separate
> WAKEUP to say "it's done" or signal error.  So most messages are standalone
> and can be used by the daemon without nnpfs requesting it.  It's useful for
> readahead of data and stat nodes.

That is very, very cool.


> For now, we put one block in each cache file for simplicity.



>>     complex mapping of (localfs_inode,offset)<->(remotefs_vnode,block#)?

> The offset "is" the block#, I'd say (cache block handle)<->(fid,offset)

I see!  Thank you for clarifying this.  This definately makes the
mapping simpler.


> We're not yet clear about how to implement the cache policies (LRU?), but
> the bookkeeping looks like it will be scary.

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)...


> If y'all want to split nnpfs discussions to new list, convince me.  I just
> haven't seen a need yet.

No, that's fine; just wanted to make sure I was in the right place.

  - a


-- 
PGP/GPG: 5C9F F366 C9CF 2145 E770  B1B8 EFB1 462D A146 C380