[PATCH 0/11] nfsacl

[PATCH 0/11] nfsacl

[Andreas Gruenbacher]

Hello,

this is the nfsacl protocol extension that implements setting/retrieving
acls over NFSv3. (It has nothing to do with NFSv4 acls, which are very
different.) Any chance we can get this into -mm, and into mainline after
some more exposure? The patches are:

sunrpc-enosys-when-unavail
   Differentiate between program/procedure not available and
   other errors. Required so that nfs clients know whether or
   not the server supports nfsacl.

sunrpc-multiple-programs
   Support multiple program numbers on one RPC transport. The nfs
   and nfsacl RPC programs both run on the same transport, so
   we need to multiplex.

rpcsvc-pages
   Add a page to an rpc reply from the allocated pool.

sunrpc-xdr-words
   Encode 32-bit words in xdr_buf's. The code is modeled after the
   decode functions already in 2.6.6-rc2.

sunrpc-xdr-arrays
   sunrpc: Encode/decode arrays that may become large.

nfsacl-lazy-alloc
   Allow to allocate pages in the receive buffers lazily. ACLs may have
   up to 1024 entries in nfsacl but usually are small, so allocating
   space for them on demand makes sense.

nfs-access-acl
   NFS mount parameter noacl: Allow clients to mount without using
   the ACCESS remote procedure call.

qsort
   Add qsort, needed for decoding acls from nfsacl.

xfs-no-qsort
   Remove qsot from xfs. Without, qsort would be defined twice in the
   kernel.

nfsd-acl
   Server nfsacl support.

nfs-acl
   Client nfsacl support.


Cheers,
-- 
Andreas Gruenbacher <agruen@suse.de>
SUSE Labs, SUSE LINUX AG

Re: [PATCH 0/11] nfsacl

[J. Bruce Fields]

On Mon, Apr 26, 2004 at 12:28:47PM +0200, Andreas Gruenbacher wrote:
> nfsacl-lazy-alloc
>    Allow to allocate pages in the receive buffers lazily. ACLs may have
>    up to 1024 entries in nfsacl but usually are small, so allocating
>    space for them on demand makes sense.

Is there any reason we couldn't set the maximum smaller than that?  It
looks like the acl entries are pretty compact (12 bytes if I'm reading
the xdr code right?) so if we limited the length of an xdr-encoded acl
to a page that would still allow a few hundred entries.  Are there
really people that need 1000-entry acls?

--Bruce Fields

Re: [PATCH 0/11] nfsacl

[Andreas Gruenbacher]

On Tue, 2004-04-27 at 17:18, J. Bruce Fields wrote:
> On Mon, Apr 26, 2004 at 12:28:47PM +0200, Andreas Gruenbacher wrote:
> > nfsacl-lazy-alloc
> >    Allow to allocate pages in the receive buffers lazily. ACLs may have
> >    up to 1024 entries in nfsacl but usually are small, so allocating
> >    space for them on demand makes sense.
> 
> Is there any reason we couldn't set the maximum smaller than that?  It
> looks like the acl entries are pretty compact (12 bytes if I'm reading
> the xdr code right?) so if we limited the length of an xdr-encoded acl
> to a page that would still allow a few hundred entries.  Are there
> really people that need 1000-entry acls?

Well, that's what the protocol allows so I don't see why we shouldn't
implement it fully. Besides, nfsacl-lazy-alloc benefits the common case
even more, because with small acls that fit into xdr_buf->head entirely,
no page needs to be allocated.

Cheers,
-- 
Andreas Gruenbacher <agruen@suse.de>
SUSE Labs, SUSE LINUX AG

Re: [PATCH 0/11] nfsacl

[J. Bruce Fields]

On Tue, Apr 27, 2004 at 05:51:47PM +0200, Andreas Gruenbacher wrote:
> On Tue, 2004-04-27 at 17:18, J. Bruce Fields wrote:
> > On Mon, Apr 26, 2004 at 12:28:47PM +0200, Andreas Gruenbacher wrote:
> > > nfsacl-lazy-alloc
> > >    Allow to allocate pages in the receive buffers lazily. ACLs may have
> > >    up to 1024 entries in nfsacl but usually are small, so allocating
> > >    space for them on demand makes sense.
> > 
> > Is there any reason we couldn't set the maximum smaller than that?  It
> > looks like the acl entries are pretty compact (12 bytes if I'm reading
> > the xdr code right?) so if we limited the length of an xdr-encoded acl
> > to a page that would still allow a few hundred entries.  Are there
> > really people that need 1000-entry acls?
> 
> Well, that's what the protocol allows so I don't see why we shouldn't
> implement it fully. Besides, nfsacl-lazy-alloc benefits the common case
> even more, because with small acls that fit into xdr_buf->head entirely,
> no page needs to be allocated.

Hm, so looks like xdr_buf->head would fit about 150 entries.  Couldn't
that be enough?

--Bruce Fields