On Tue, 28 May 2013 20:38:57 -0700 Frank S Filz <ffilz@xxxxxxxxxx> wrote: > > Jim Lieb <jlieb@xxxxxxxxxxx> wrote on 05/28/2013 05:57:31 PM: > > > Actually, ACLs are critical for Ganesha. Unless we decide to have > separate > > > attr validity bits for "stat" attributes and ACLs, Ganesha will have a > > > difficult time knowing if the ACL attribute is up to date (or even > > > available). > > > > True enough. But one of the pushbacks was the amount of work neededto > get to > > xattrs where acls live. One thing I heard that made not having acls on > the > > readdir+ pass was a status of some kind that indicated "I have acls..." > The > > readdir is a dir op and so 10k+ entries need to be minimal overhead. we > > already have the acls of the dir from the lookup. we don't need an > entry's > > acls until we do the lookup on it. at that time we can grab the acls. > That > > was the argument as I remember and I'm willing to accept it. IIRC, > > the client > > is going to send us a getattrs later. we can do it then. Is this > reasonable? > > The ACL COULD be required on READDIR, though I would not expect any clients > to ask for ACL on READDIR (though it sure would be handy if Ganesha's PROXY > client could do so...). > > Fortunately we don't enforce ACE4_READ_ATTR, otherwise we WOULD need ACL on > any READDIR... > > If there are times when we get attrs without getting ACL, then we will need > a separate validity bit for ACL, otherwise we won't be able to tell if we > have current ACL for an entry or not. > > What would actually be helpful though, and make Ganesha a lot more > efficient is if we could actually get all the ACLs for a directory in one > fell swoop with some sort of "compression". Given that a large percentage > of files actually have the same ACL, we could get a the 1-4 ACLs that > apply, and then a bunch of entries, each indicating which of the 4 ACLs > they have. > Most NFS clients aren't going to need ACLs during a READDIR operation. I'll go as so far to say that most NFS clients don't care *at all* about ACLs. Those are things that are enforced by the server and the client doesn't really care to know about them. The exception is when a client gets an explicit request to either view or change the ACL. For Linux clients (and most other POSIX-y ones), that's never done in any sort of batch form. It's always an operation done against a single dentry. So, I'm not sure I understand the argument for adding ACLs here. It's not likely to be something you're going to end up stuffing into a READDIR reply. -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
