On Wed, May 29, 2013 at 06:06:09AM -0400, Jeff Layton wrote: > 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. An odd exception: in the presence of "posix" acls, "ls -l" requests an acl for every entry, so it can decide whether or not to add a "+" after the mode (which indicates the presence of a non-trivial acl.) Judging from http://www.bestbits.at/richacl/example.html, the same is intended (but not yet implemented) for richacls. Maybe if that case were common, there'd be some advantage to ls being able to do a readdir plus to the nfs client that the nfs client could translate into a single readdir to the server? But I hope it doesn't come to that. --b. > 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
