Does NFSv4 involve caching? If so, might working out a common cache API be of
use to you?
David
>>>>> " " == David Howells <[email protected]> writes:
> Does NFSv4 involve caching? If so, might working out a common
> cache API be of use to you?
NFSv4 does not specify that files need to be backed by local storage
the way AFS does if that is what you mean. However it does offer
AFS-like features (such as file delegation / leases) that make a
cachefs a much more feasible proposition.
I, for one, would be very interested in seeing a cachefs add-on for
NFSv4. I think that it would be of great use for GRID / distributed
computation applications, which is where my personal interest in NFSv4
lies.
Cheers,
Trond
> NFSv4 does not specify that files need to be backed by local storage
> the way AFS does if that is what you mean. However it does offer
> AFS-like features (such as file delegation / leases) that make a
> cachefs a much more feasible proposition.
>
> I, for one, would be very interested in seeing a cachefs add-on for
> NFSv4. I think that it would be of great use for GRID / distributed
> computation applications, which is where my personal interest in NFSv4
> lies.
Can you give me some sort of idea as to what keys I might use for indexing?
For instance, AFS has the following:
PRIMARY KEY SIZE AUXILLIARY DATA IN INDEX
============== ============== ============================
cell name up to 64 ASCII - volume location database
server addresses
volume ID 32-bit number - name of volume
- associated keys
- fileserver addresses
vnode ID 32-bit number - access time
- vnode metadata record pointer
- vnode ID version
- vnode data version
- modify time
- size
- data block pointers
Each index entry of course has a pointer back up the hierarchy.
Furthermore, to determine whether a cached file's contents are still valid, I
can compare the the vnode ID version and vnode data version numbers against
the server.
Not all these indices and keys will necessarily be useful for NFS.
David