Steve Dickson wrote:
Peter Staubach wrote:
2. Use a radix tree per inode.
Using radix trees actual makes things much simpler... Good idea, imo.
It does seem like a good idea, although just using the uid is not
sufficient
to identify the correct access cache entry. The group and groups
list must
also be used. Can the radix tree implementation support this?
We could use (nfsi + uid) as the index... but its not clear what that
would buys us... And the group and group list were never part of the
cache in the first place.... is this something you feel needs to be
added or am I just not understanding....
Yes, I believe that the entire user identification, uid, gid, groups list,
needs to be used to identify the correct cache entry. An easy example of
differing access rights, but with the same uid, is an application which is
setgid.
I believe that the "key" to the cache entry should be the entire user
identification that the NFS server sees and uses when calculating access
rights. Using the uid as part of a hash key is okay and probably a good
idea, but I don't think that the uid is sufficient to completely identify
a specific cache entry.
Given this, then I suspect that the current access cache is broken...
Thanx...
ps
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
