[patch] NFSv4/ZFS ACLs

[Wayne Davison]

On Sat, Jun 9, 2012 at 2:19 PM, Richard P <richardp345 at gmail.com> wrote:

> This is a PoC patch for NFSv4/ZFS ACLs.
>

Much appreciated.  Your patch looks like it has some nice ideas that I'd
like to get integrated into rsync.  Sorry for the huge delay in getting
back to you.

Linux and Solaris represent NFSv4 ACLs differently and provide no API
> to serialize them in a platform-independent format so this patch treats the
> ACLs as platform-dependent opaque data.
>

There are two potential methods for sending  non-posix ACL info -- change
the ACL-sending code (as you have done) or put the info into xattr data.
 In retrospect, I think it would have been better to have unified the ACL
and xattr code in rsync into a single aux-data-sending protocol from the
start, rather than keeping things separate.  So, one possibility is that we
should just be faking system xattr data for solaris NFSv4 data, and sending
Linux NFSv4 xattr data via xattrs.  That would require the code to have a
mode where it could send just the "system" ACL xattrs without affecting
user xattrs (with the ability to send system xattrs being something new).

So, I'm debating whether I like your method or not.  It looks like it does
a nice job of implementing a revised ACL protocol, with just a little more
todos and rearranging (as you noted).  What do you (and anyone else) think
about an xattr solution?  One consideration is the coalescing of common
values -- this is currently done separately for ACLs and xattrs, which is
probably more efficient (since the matching of ACLs is more likely to be a
small set), and the xattr-matching code is not very efficient.  So, I'm not
sure which I like better just yet.

 * wasn't sure how to SUBPROTOCOL_VERSION worked so I've revved
> PROTOCOL_VERSION to 31
>

I'm already using protocol 31 in the dev version, so your version will fail
to sync with a future released 3.1.0 rsync (which is when the subprotocol
version goes to 0).  For a non-standard protocol, you should increase the
PROTOCOL_VERSION and set the SUBPROTOCOL_VERSION to a unique value (never
one near an official value -- pick any fairly big, unique number).

..wayne..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/rsync/attachments/20120721/ed1fe7d1/attachment.html>