On Mon, Nov 04, 2019 at 04:21:47PM +0000, Frank van der Linden wrote: > On Mon, Nov 04, 2019 at 10:36:03AM -0500, Chuck Lever wrote: > > > > Following the server's local file systems' mount options seems like a > > good way to go. In particular, is there a need to expose user xattrs > > on the server host, but prevent NFS clients' access to them? I can't > > think of one. > > Ok, that sounds fine to me - I'll remove the user_xattr export flag, > and we had already agreed to do away with the CONFIGs. > > That leaves one last item with regard to enabling support: the client side > mount option. I assume the [no]user_xattr option should work the same as > with other filesystems. What about the default setting? Just checking code for other filesystems quickly; if I understand right: - ext4 has user_xattr and nouser_xattr options, but you get a deprecation warning if you try to use the latter; - xfs doesn't support either option; - cifs supports both, with xattr support the default. Not necessarily my call, but just for simplicity's sake, I'd probably leave out the option and see if anybody complains. > Also, currently, my code does not fail the mount operation if user xattrs > are asked for, but the server does not support them. It just doesn't > set NFS_CAP_XATTR for the server, and the xattr handler entry points > eturn -EOPNOTSUPP, as they check for NFS_CAP_XATTR. What's the preferred > behavior there? getxattr(2) under ERRORS says: ENOTSUP Extended attributes are not supported by the filesystem, or are disabled. so I'm guessing just erroring out is clearest. I also see there's an EOPNOTSUPP return in the nouser_xattr case in ext4_xattr_user_get. (errno(3) says ENOTSUP and EOPNOTSUPP are the same value on Linux.) --b.
