Re: [1/8] readdir-plus system call - LSF/MM follow up

["J. Bruce Fields" <bfields@redhat.com>]

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@us.ibm.com> wrote:
> 
> > 
> > Jim Lieb <jlieb@panasas.com> 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@redhat.com>