Re: [PATCH v2 00/13] NFS client user xattr (RFC8276) support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




----- Original Message -----
> From: "Frank van der Linden" <fllinden@xxxxxxxxxx>
> To: "Tigran Mkrtchyan" <tigran.mkrtchyan@xxxxxxx>
> Cc: "linux-nfs" <linux-nfs@xxxxxxxxxxxxxxx>, "Anna Schumaker" <anna.schumaker@xxxxxxxxxx>, "Trond Myklebust"
> <trond.myklebust@xxxxxxxxxxxxxxx>
> Sent: Friday, March 27, 2020 12:16:02 AM
> Subject: Re: [PATCH v2 00/13] NFS client user xattr (RFC8276) support

> On Thu, Mar 26, 2020 at 08:03:13PM +0100, Mkrtchyan, Tigran wrote:
>> The new patchset looks broken to me.
>> 
>> Client quiryes for supported attributes and gets xattr_support bit set:
>> 
>> Mar 26 11:27:07 ani.desy.de kernel: decode_attr_supported:
>> bitmask=fcffbfff:40fdbe3e:00040800
>> 
>> However, the attribute never queries, but client makes is decision:
>> 
>> Mar 26 11:27:07 ani.desy.de kernel: decode_attr_xattrsupport: XATTR
>> support=false
>> 
>> The packets can be found here: https://sas.desy.de/index.php/s/GEPiBxPg3eR4aGA
>> 
>> Can you provide packets of your mount/umount round.
> 
> Hi Tigran,
> 
> I looked at your packet dump. It seems like your server only supports 4.1,
> not 4.2. xattr support builds on 4.2 (within the rules laid out in
> RFC 8178).

That's right, this is what rfc8276 says:

   Note that the XDR code contained in this document depends on types
   from the NFSv4.2 nfs4_prot.x file [RFC7863].  This includes both nfs
   types that end with a 4, such as nfs_cookie4, count4, etc., as well
   as more-generic types, such as opaque and bool.

However, xattr support doesn't relays on any functionality provided by v4.2. Moreover,
all used data structures (nfs_cookie4, component4, change_info4) defined in nfsv4.0.
Thus there are no reasons why even v4.0 server can't support xattrs.

> 
> So, the fsinfo client call, which is just a GETATTR, masks out the 4.2
> fattr bits from server->attr_mask, and just uses the 4.1 bits. Meaning that
> xattr_support is not included, and defaults to false.

I was expecting something like this, but was unable to find the place where this
masking is happening.

Tigran.

> 
> The packet dump also indicates that your server advertises the xattr_support
> fattr as supported, even though it's in a 4.1 session, which would not
> be correct.
> 
> - Frank



[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux