is cache-only-prefixes an nnpfs limitation?

[Adam Megacz]

Tomas Olsson <tol at stacken.kth.se> writes:
> At the moment I'm using 8k, but it probably won't get any smaller.

That's fine.

Also, I noticed this in docs/caching-in-blocks:

  "There is just one reson that one should have blockcache.  You want
   to edit filer larger then you blockcache"

Actually, I'm most interested in block caching for a different reason
-- I often store large media files in AFS and seek around in them (ie
access starting at random locations in the file).  Many of these files
would fit in my disk cache, but moving the entire file over the
network or crowding (almost) everything else out of my local cache
would be bad.


> If you have any thoughts on the subject (protocol?), let me know.

In particular, I'm most curious about the flexibility of the
nnpfs<->localfs interface.  If I understand correctly, when used with
arlad, nnpfs never gets file data directly from arlad -- it just asks
arlad to place the file data in a particular file and then let the
kernel know that it's there (the kernel then gets that data out of the
file using the local fs driver).  So, when nnpfs is used *outside* the
context of arla:

  - Do remote-filesystem file have to map 1:1 exactly to local files?
    Or do remote blocks map to local files?  Or do remote blocks map
    to local blocks?  I'm assuming the block-mode caching driver must
    have dealt with this issue...

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

I tried reading ./nnpfs/include/nnpfs/nnpfs_message.h from the block
branch, and it seems to me that when the userland replies with an
INSTALLDATA message, it tells the kernel not only what localfs file
contains the requested block, but also *at what offset* in the localfs
file the requested remotefs block is located.

  - Does this mean that the nnpfs kernel module maintains a big
    complex mapping of (localfs_inode,offset)<->(remotefs_vnode,block#)?

      - Or does it just cache a subset of this information and rely on
        calls back to userland to "remind" it of mappings which it may
        have forgotten?

Lastly, is there a separate nnpfs mailing list, or is this the right
place to discuss these questions?


> cached operations, and a huge margin to the OpenAFS client at the time. I
> haven't done any benchmarking since, but a 14x performance gain for cached
> reads is impressive, don't you think :)

Absolutely.

IMHO, the most compelling thing for me is that nnpfs is basically the
only way to:

  - create a filesystem driver that runs on both Win32 and *nix
  - from a single codebase
  - without resorting to NFS/SMB-translators

I think that's pretty neat.

  - a

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