I can't tell what you are asking here, so I'll describe the datastructure that is actually used.So do you use the PAG to reference a per-user index of access control rights for a collection of files, or do you use the PAG to check access against the cached copy in a global shared cache?
Each cached vnode has a pointer to a linked list of struct axscache entries. Each entry maps a pag/user id to it's effective access rights.
The client does not compute the access rights by evaluating the ACL. The client gets the access rights from the fileserver. The fileserver computes the _effective_ rights of the caller on every FetchStatus request and returns that information to the client. The client updates the axscache entry as part of processing the FetchStatus response. later permission() calls (and some internal users) can use this information instead of asking the fileserver, as long as the callback is still valid..In the latter case, you would just cache the ACL sent by the fileserver and check against the principal name/id stored in the key and global cache.
Not that this has anything to do with PAGs, what rx implementation we use, or the axscache...I'm just trying to understand what part of the existing Linux filesystem cache is insufficient for OpenAFS to utilize without resorting to patched-in external caches.
Are you talking about the current pagecache, or the as yet non-mainline cachefs?
If the former:
The afs data cache's working set can be larger than the memory reserved for the pagecache.
The afs data cache persists across reboots. The client validates stored chunks by comparing the dataversion stored in the cache with that reported by the fileserver. if the dv is the same, the cached data is valid and may be returned to clients without transferring them over the network.
If the latter, then it probably is or could be made sufficient. The following things would be needed.
- The ability to choose the 'key' that identifies cached objects. afs will always need to index things by (cell,volume,vnode,uniquifier), and not by filename. If cachefs doesn't help with chunking, tjhen the chunk number or offset would also need to be part of the key.
- the ability to store metadata about each cached object (the DV and some flags)
- A place to persistently store global metadata (the cell name to id map)
I think the following would also be needed:
- The ability to do range searches (partial key matches) (so that everything in a (cell, volume) could be evicted from the cache on an fs flushv, or all chunks of a single file, if chunking is implemented by having multiple cachefs objects)
It comes back to that portability issue though. Having a 'better' interface to use on linux does not help us on the other platforms, and actually increases complexity by requiring some sort of abstraction layer that can be used to provide uniform access to the two cache implementations. Also, at what point do we cross the line alluded to in <http://www.linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html>, and become code "written for linux" instead of "(a filesystem) ported from other operating systems"?
p7s8ULHLcLwgr.p7s
Description: S/MIME cryptographic signature
