From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. Bruce Fields" Subject: Re: [1/8] readdir-plus system call - LSF/MM follow up Date: Wed, 29 May 2013 10:04:56 -0400 Message-ID: <20130529140456.GA28385@pad.fieldses.org> References: <516299A5.8030109@panasas.com> <1849331.etDWltRNrI@jlieb-e6410> <6063990.7MGE7UW7Zr@jlieb-e6410> <20130529060609.434ac247@corrin.poochiereds.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Frank S Filz , Jim Lieb , Abhijith Das , Boaz Harrosh , Dave Chinner , Venkateswararao Jujjuri , linux-fsdevel , lsf-pc@lists.linux-foundation.org, Ganesha NFS List , DENIEL Philippe , Steve Dickson , Steven Whitehouse , Zach Brown To: Jeff Layton Return-path: Received: from mx1.redhat.com ([209.132.183.28]:17226 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752755Ab3FDPeI (ORCPT ); Tue, 4 Jun 2013 11:34:08 -0400 Content-Disposition: inline In-Reply-To: <20130529060609.434ac247@corrin.poochiereds.net> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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 wrote: > > > > > Jim Lieb 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