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 <[email protected]>
SUSE Labs, SUSE LINUX AG
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
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 <[email protected]>
SUSE Labs, SUSE LINUX AG
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