From: Jim Lieb <jlieb@panasas.com>
To: Frank S Filz <ffilz@us.ibm.com>
Cc: Abhijith Das <adas@redhat.com>,
"J. Bruce Fields" <bfields@redhat.com>,
Boaz Harrosh <bharrosh@panasas.com>,
Dave Chinner <dchinner@redhat.com>,
Jeff Layton <jlayton@redhat.com>,
Venkateswararao Jujjuri <jvrao@linux.vnet.ibm.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
<lsf-pc@lists.linux-foundation.org>,
Ganesha NFS List <nfs-ganesha-devel@lists.sourceforge.net>,
DENIEL Philippe <philippe.deniel@cea.fr>,
Steve Dickson <steved@redhat.com>,
Steven Whitehouse <swhiteho@redhat.com>,
Zach Brown <zab@redhat.com>
Subject: Re: Re: Re: Re: [1/8] readdir-plus system call - LSF/MM follow up
Date: Wed, 29 May 2013 09:52:39 -0700 [thread overview]
Message-ID: <1473127.WSgmrlzxQN@jlieb-e6410> (raw)
In-Reply-To: <OF067A3B49.F63109B6-ON87257B7A.00137A60-88257B7A.00140BC7@us.ibm.com>
On Tuesday, May 28, 2013 20:38:57 Frank S Filz 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...
That's an acl on the dir itself. If we carry this further, a recursive ls
would readdir+ the top level dir, then lookup each dir in its list in order to
get a handle for the next level of readdir+. At the time of the lookup is
when we need the acl for that dir. If anywhere in the tree we have 5 dirs and
10k "other" files, regulars, symlinks etc., we only really need the acl above
for the 5 dirs. We take the getattr (+get acls) hit 5 times at lookup time
for that dir. The 10k other stuff is happy with name, ls -l stuff.
>
> 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.
>
> Frank
--
Jim Lieb
Linux Systems Engineer
Panasas Inc.
next prev parent reply other threads:[~2013-05-29 16:53 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-08 10:19 [LSF/MM TOPIC (expanded) 0/8] New API's for better exporting of VFS from user-mode daemons Boaz Harrosh
2013-04-08 10:22 ` [1/8] readdir-plus system call Boaz Harrosh
2013-04-08 10:26 ` Steven Whitehouse
2013-04-08 15:18 ` [Nfs-ganesha-devel] " Matt W. Benjamin
2013-04-08 13:51 ` DENIEL Philippe
2013-04-08 19:02 ` Abhijith Das
2013-04-10 20:31 ` Andreas Dilger
2013-05-24 16:14 ` [1/8] readdir-plus system call - LSF/MM follow up Abhijith Das
2013-05-24 19:41 ` Zach Brown
2013-05-28 14:49 ` Abhijith Das
2013-05-28 15:13 ` Jim Lieb
[not found] ` <OF27E1911F.3FBABA22-ON87257B79.005C087F-88257B79.005C320B@us.ibm.com>
2013-05-29 0:57 ` Jim Lieb
[not found] ` <OF067A3B49.F63109B6-ON87257B7A.00137A60-88257B7A.00140BC7@us.ibm.com>
2013-05-29 10:06 ` Jeff Layton
2013-05-29 14:04 ` J. Bruce Fields
2013-06-04 15:38 ` [Lsf-pc] " Christoph Hellwig
2013-06-04 15:52 ` J. Bruce Fields
2013-05-29 16:52 ` Jim Lieb [this message]
2013-05-28 20:00 ` Andreas Dilger
2013-05-28 20:11 ` Abhijith Das
2013-04-08 10:25 ` [LSF/MM TOPIC (expanded) 0/8] New API's for better exporting of VFS from user-mode daemons Steven Whitehouse
2013-04-08 10:25 ` [2/8] Sane locks (UNPOSIX locks) Boaz Harrosh
2013-04-08 12:02 ` [Lsf-pc] " Jeff Layton
2013-04-08 10:28 ` [3/8] File delegations, Usermode API of Bruce's pending patches Boaz Harrosh
2013-04-08 10:32 ` [4/8] PNFS ioctls/syscall Boaz Harrosh
2013-04-08 10:36 ` [5/8] syscall_cred() a system call that receives alternate CREDs Boaz Harrosh
2013-04-08 13:54 ` DENIEL Philippe
2013-04-08 14:42 ` J. Bruce Fields
2013-04-08 14:58 ` Boaz Harrosh
2013-04-08 18:23 ` Jim Lieb
2013-04-08 18:31 ` J. Bruce Fields
2013-04-08 19:45 ` Jim Lieb
2013-04-08 21:33 ` Boaz Harrosh
2013-04-09 16:40 ` Jim Lieb
2013-04-08 10:42 ` [6/8] Rich ACLs (continued, drive through this time) Boaz Harrosh
2013-04-08 11:12 ` Vyacheslav Dubeyko
2013-04-08 14:27 ` Venkateswararao Jujjuri
2013-04-08 10:43 ` [7/8] Single call interface to getattr/setattr Boaz Harrosh
[not found] ` <OF4A1A78E0.CB4DED3E-ON87257B47.00549E35-88257B47.005520A8@us.ibm.com>
2013-04-08 16:41 ` Boaz Harrosh
2013-04-08 10:45 ` [8/8] Fix fsnotify short comings (single fd with recursive notifications) Boaz Harrosh
2013-04-08 13:59 ` DENIEL Philippe
2013-04-08 15:22 ` Al Viro
2013-04-08 15:36 ` J. Bruce Fields
2013-04-08 14:31 ` [LSF/MM TOPIC (expanded) 0/8] New API's for better exporting of VFS from user-mode daemons Venkateswararao Jujjuri
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1473127.WSgmrlzxQN@jlieb-e6410 \
--to=jlieb@panasas.com \
--cc=adas@redhat.com \
--cc=bfields@redhat.com \
--cc=bharrosh@panasas.com \
--cc=dchinner@redhat.com \
--cc=ffilz@us.ibm.com \
--cc=jlayton@redhat.com \
--cc=jvrao@linux.vnet.ibm.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=nfs-ganesha-devel@lists.sourceforge.net \
--cc=philippe.deniel@cea.fr \
--cc=steved@redhat.com \
--cc=swhiteho@redhat.com \
--cc=zab@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).