Thanks for clarification. Tigran. ----- Original Message ----- > From: "Anna Schumaker" <anna.schumaker@xxxxxxxxxx> > To: "Tigran Mkrtchyan" <tigran.mkrtchyan@xxxxxxx> > Cc: "linux-nfs" <linux-nfs@xxxxxxxxxxxxxxx>, "Trond Myklebust" <trond.myklebust@xxxxxxxxxxxxxxx>, "Frank van der Linden" > <fllinden@xxxxxxxxxx> > Sent: Monday, June 8, 2020 6:15:06 PM > Subject: Re: [PATCH v2 00/13] NFS client user xattr (RFC8276) support > Hi Tigran, > > > On Mon, Jun 8, 2020 at 11:59 AM Mkrtchyan, Tigran > <tigran.mkrtchyan@xxxxxxx> 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@xxxxxxx> >> > To: "Frank van der Linden" <fllinden@xxxxxxxxxx> >> > Cc: "linux-nfs" <linux-nfs@xxxxxxxxxxxxxxx>, "Anna Schumaker" >> > <anna.schumaker@xxxxxxxxxx>, "Trond Myklebust" >> > <trond.myklebust@xxxxxxxxxxxxxxx> >> > 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@xxxxxxx> >> > Date: Fri, Mar 27, 2020, 08:51 >> > To: Frank van der Linden <fllinden@xxxxxxxxxx> >> > Cc: linux-nfs <linux-nfs@xxxxxxxxxxxxxxx>, Anna Schumaker >> > <anna.schumaker@xxxxxxxxxx>, Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> >> > Subject: Re: [PATCH v2 00/13] NFS client user xattr (RFC8276) support >> > >> > >> > ----- 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
