| Message ID | 20200325231051.31652-1-fllinden@amazon.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | NFS client user xattr (RFC8276) support | expand |
Hi Frank. ----- Original Message ----- > From: "Frank van der Linden" <fllinden@amazon.com> > To: "linux-nfs" <linux-nfs@vger.kernel.org>, "Anna Schumaker" <anna.schumaker@netapp.com>, "Trond Myklebust" > <trond.myklebust@hammerspace.com> > Cc: "Frank van der Linden" <fllinden@amazon.com> > Sent: Thursday, March 26, 2020 12:10:38 AM > Subject: [PATCH v2 00/13] NFS client user xattr (RFC8276) support > v1 is here: https://www.spinics.net/lists/linux-nfs/msg76740.html > > v2: > > * Move nfs4 specific definitions to nfs_fs4.h > * Squash some patches together to avoid unused function warnings > when bisecting. > * Made determining server support a two-step process. First, > the extended attribute FATTR is verified to be supported, then > the value of the attributed is queried in fsinfo to determine > support. 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. Regards, Tigran. > * Fixed up Makefile to remove an unneeded extra line. > > This was tested as before (using my own stress tests), but also > with xfstests-dev. No issues were found, but xfstests needs some > fixes to correctly run the applicable xattr tests on NFS. I > have those changes, but need to send them out. > > I also tested stress-ng-xattr with 1000 workers on the client > side, running for 8 hours without problems (except for noting > that the session tbl_lock can become quite hot when doing > NFS operations by 1000 threads, but that's a separate issue). > > > Frank van der Linden (13): > nfs,nfsd: NFSv4.2 extended attribute protocol definitions > nfs: add client side only definitions for user xattrs > NFSv4.2: define limits and sizes for user xattr handling > NFSv4.2: query the server for extended attribute support > NFSv4.2: add client side XDR handling for extended attributes > nfs: define nfs_access_get_cached function > NFSv4.2: query the extended attribute access bits > nfs: modify update_changeattr to deal with regular files > nfs: define and use the NFS_INO_INVALID_XATTR flag > nfs: make the buf_to_pages_noslab function available to the nfs code > NFSv4.2: add the extended attribute proc functions. > NFSv4.2: hook in the user extended attribute handlers > NFSv4.2: add client side xattr caching. > > fs/nfs/Makefile | 2 +- > fs/nfs/client.c | 22 +- > fs/nfs/dir.c | 24 +- > fs/nfs/inode.c | 16 +- > fs/nfs/nfs42.h | 24 + > fs/nfs/nfs42proc.c | 248 ++++++++ > fs/nfs/nfs42xattr.c | 1083 +++++++++++++++++++++++++++++++++++ > fs/nfs/nfs42xdr.c | 438 ++++++++++++++ > fs/nfs/nfs4_fs.h | 35 ++ > fs/nfs/nfs4client.c | 31 + > fs/nfs/nfs4proc.c | 237 +++++++- > fs/nfs/nfs4super.c | 10 + > fs/nfs/nfs4xdr.c | 31 + > fs/nfs/nfstrace.h | 3 +- > include/linux/nfs4.h | 25 + > include/linux/nfs_fs.h | 12 + > include/linux/nfs_fs_sb.h | 6 + > include/linux/nfs_xdr.h | 60 +- > include/uapi/linux/nfs4.h | 3 + > include/uapi/linux/nfs_fs.h | 1 + > 20 files changed, 2269 insertions(+), 42 deletions(-) > create mode 100644 fs/nfs/nfs42xattr.c > > -- > 2.17.2
On Thu, Mar 26, 2020 at 08:03:13PM +0100, Mkrtchyan, Tigran wrote: > Hi Frank. > > 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. > > Regards, > Tigran. Hi Tigran, This patchset works against the server side patches, and also works against a FreeBSD-current server. Is this failure happening with your Java server? Let me look at your packet dump and compare it with a working scenario. - Frank
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). 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. 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
----- 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
Dear maintainers, are those changes considered for 5.8? 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
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
Thanks for clarification. Tigran. ----- Original Message ----- > From: "Anna Schumaker" <anna.schumaker@netapp.com> > To: "Tigran Mkrtchyan" <tigran.mkrtchyan@desy.de> > Cc: "linux-nfs" <linux-nfs@vger.kernel.org>, "Trond Myklebust" <trond.myklebust@hammerspace.com>, "Frank van der Linden" > <fllinden@amazon.com> > 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@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
On Mon, Jun 08, 2020 at 06:37:29PM +0200, Mkrtchyan, Tigran wrote: > Thanks for clarification. > > Tigran. > > ----- Original Message ----- > > From: "Anna Schumaker" <anna.schumaker@netapp.com> > > To: "Tigran Mkrtchyan" <tigran.mkrtchyan@desy.de> > > Cc: "linux-nfs" <linux-nfs@vger.kernel.org>, "Trond Myklebust" <trond.myklebust@hammerspace.com>, "Frank van der Linden" > > <fllinden@amazon.com> > > 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@desy.de> wrote: > >> > >> > >> Dear maintainers, > >> > >> are those changes considered for 5.8? > > > > My understanding is that these patches will be targeting 5.9. > > > > Anna Hi Tigran, Since there is one remaining open issue on the server side changes that needs signoff from the general fs maintainers, I agreed with Bruce & Chuck to target 5.9, as the 5.8 merge window is currently already open, and all the activity is centered around it. For the client side, there are no open issues that were flagged, so from my side it's all ready to go - except for me to post a v3 rebased to the latest tree, which is easy to do. In other words, I think it's ok for the client side to go in to 5.8, but it probably makes more sense to have it go in to the same version as the server side, so that's what I proposed to Anna & Trond. - Frank
Hi Frank, ----- Original Message ----- > From: "Frank van der Linden" <fllinden@amazon.com> > To: "Tigran Mkrtchyan" <tigran.mkrtchyan@desy.de> > Cc: "Anna Schumaker" <anna.schumaker@netapp.com>, "linux-nfs" <linux-nfs@vger.kernel.org>, "Trond Myklebust" > <trond.myklebust@hammerspace.com> > Sent: Monday, June 8, 2020 6:47:42 PM > Subject: Re: [PATCH v2 00/13] NFS client user xattr (RFC8276) support > On Mon, Jun 08, 2020 at 06:37:29PM +0200, Mkrtchyan, Tigran wrote: >> Thanks for clarification. >> >> Tigran. >> >> ----- Original Message ----- >> > From: "Anna Schumaker" <anna.schumaker@netapp.com> >> > To: "Tigran Mkrtchyan" <tigran.mkrtchyan@desy.de> >> > Cc: "linux-nfs" <linux-nfs@vger.kernel.org>, "Trond Myklebust" >> > <trond.myklebust@hammerspace.com>, "Frank van der Linden" >> > <fllinden@amazon.com> >> > 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@desy.de> wrote: >> >> >> >> >> >> Dear maintainers, >> >> >> >> are those changes considered for 5.8? >> > >> > My understanding is that these patches will be targeting 5.9. >> > >> > Anna > > Hi Tigran, > > Since there is one remaining open issue on the server side changes that needs > signoff from the general fs maintainers, I agreed with Bruce & Chuck to target > 5.9, as the 5.8 merge window is currently already open, and all the activity > is centered around it. > > For the client side, there are no open issues that were flagged, so from my > side it's all ready to go - except for me to post a v3 rebased to > the latest tree, which is easy to do. > > In other words, I think it's ok for the client side to go in to 5.8, but it > probably makes more sense to have it go in to the same version as the server > side, so that's what I proposed to Anna & Trond. Makes sense. Thanks, Tigran. > > - Frank