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

Anna Schumaker
2020-06-08T16:15:25Z

Hi Tigran,

On Mon, Jun 8, 2020 at 11:59 AM Mkrtchyan, Tigran
<tigran.mkrtchyan@desy.de> wrote:
>
>
> Dear maintainers,
>
> are those changes considered for 5.8?

My understanding is that these patches will be targeting 5.9.

Anna
>
> Thanks,
> Tigran.
>
> ----- Original Message -----
> > From: "Tigran Mkrtchyan" <tigran.mkrtchyan@desy.de>
> > To: "Frank van der Linden" <fllinden@amazon.com>
> > Cc: "linux-nfs" <linux-nfs@vger.kernel.org>, "Anna Schumaker" <anna.schumaker@netapp.com>, "Trond Myklebust"
> > <trond.myklebust@hammerspace.com>
> > Sent: Saturday, April 4, 2020 2:18:54 PM
> > Subject: Re:[PATCH v2 00/13] NFS client user xattr (RFC8276) support
>
> > After adding 'minimal' 4.2 implementation to our server, the patchset works as
> > expected.
> > Thanks, Tigran.
> >
> > -------- Original message --------
> > From: "Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de>
> > Date: Fri, Mar 27, 2020, 08:51
> > To: Frank van der Linden <fllinden@amazon.com>
> > Cc: linux-nfs <linux-nfs@vger.kernel.org>, Anna Schumaker
> > <anna.schumaker@netapp.com>, Trond Myklebust <trond.myklebust@hammerspace.com>
> > Subject: Re: [PATCH v2 00/13] NFS client user xattr (RFC8276) support
> >
> >
> > ----- Original Message -----
> >> From: "Frank van der Linden" <fllinden@amazon.com>
> >> To: "Tigran Mkrtchyan" <tigran.mkrtchyan@desy.de>
> >> Cc: "linux-nfs" <linux-nfs@vger.kernel.org>, "Anna Schumaker"
> >> <anna.schumaker@netapp.com>, "Trond Myklebust"
> >> <trond.myklebust@hammerspace.com>
> >> 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