From: "Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de> To: linux-nfs <linux-nfs@vger.kernel.org> Cc: Anna Schumaker <anna.schumaker@netapp.com>, Trond Myklebust <trond.myklebust@hammerspace.com>, Frank van der Linden <fllinden@amazon.com> Subject: Re: [PATCH v2 00/13] NFS client user xattr (RFC8276) support Date: Mon, 8 Jun 2020 17:52:00 +0200 (CEST) Message-ID: <1684380491.969626.1591631520724.JavaMail.zimbra@desy.de> (raw) In-Reply-To: <v2aze7-yqvuvfuc4i30-1xxisr-dr39sbpkxym7-2nbcltx37gs3ezoql-qoc5f45hvih45iurdv-lqtdu9ppbm6i-upakk-2awl3v-em4ktl4ip5gchvuicg-vgnve1-wbqe5p-fw96bj-ct2sjj-wlbpk7.1586002736523@email.android.com> 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
next prev parent reply index Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-25 23:10 Frank van der Linden 2020-03-25 23:10 ` [PATCH v2 01/13] nfs,nfsd: NFSv4.2 extended attribute protocol definitions Frank van der Linden 2020-03-25 23:10 ` [PATCH v2 02/13] nfs: add client side only definitions for user xattrs Frank van der Linden 2020-03-25 23:10 ` [PATCH v2 03/13] NFSv4.2: define limits and sizes for user xattr handling Frank van der Linden 2020-03-25 23:10 ` [PATCH v2 04/13] NFSv4.2: query the server for extended attribute support Frank van der Linden 2020-03-25 23:10 ` [PATCH v2 05/13] NFSv4.2: add client side XDR handling for extended attributes Frank van der Linden 2020-03-25 23:10 ` [PATCH v2 06/13] nfs: define nfs_access_get_cached function Frank van der Linden 2020-03-25 23:10 ` [PATCH v2 07/13] NFSv4.2: query the extended attribute access bits Frank van der Linden 2020-03-25 23:10 ` [PATCH v2 08/13] nfs: modify update_changeattr to deal with regular files Frank van der Linden 2020-03-25 23:10 ` [PATCH v2 09/13] nfs: define and use the NFS_INO_INVALID_XATTR flag Frank van der Linden 2020-03-25 23:10 ` [PATCH v2 10/13] nfs: make the buf_to_pages_noslab function available to the nfs code Frank van der Linden 2020-03-25 23:10 ` [PATCH v2 11/13] NFSv4.2: add the extended attribute proc functions Frank van der Linden 2020-03-25 23:10 ` [PATCH v2 12/13] NFSv4.2: hook in the user extended attribute handlers Frank van der Linden 2020-03-25 23:10 ` [PATCH v2 13/13] NFSv4.2: add client side xattr caching Frank van der Linden 2020-03-26 19:03 ` [PATCH v2 00/13] NFS client user xattr (RFC8276) support Mkrtchyan, Tigran 2020-03-26 19:43 ` Frank van der Linden 2020-03-26 23:16 ` Frank van der Linden 2020-03-27 7:51 ` Mkrtchyan, Tigran [not found] ` <v2aze7-yqvuvfuc4i30-1xxisr-dr39sbpkxym7-2nbcltx37gs3ezoql-qoc5f45hvih45iurdv-lqtdu9ppbm6i-upakk-2awl3v-em4ktl4ip5gchvuicg-vgnve1-wbqe5p-fw96bj-ct2sjj-wlbpk7.1586002736523@email.android.com> 2020-06-08 15:52 ` Mkrtchyan, Tigran [this message] 2020-06-08 16:15 ` Anna Schumaker 2020-06-08 16:37 ` Mkrtchyan, Tigran 2020-06-08 16:47 ` Frank van der Linden 2020-06-08 16:52 ` Mkrtchyan, Tigran
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1684380491.969626.1591631520724.JavaMail.zimbra@desy.de \ --to=tigran.mkrtchyan@desy.de \ --cc=anna.schumaker@netapp.com \ --cc=fllinden@amazon.com \ --cc=linux-nfs@vger.kernel.org \ --cc=trond.myklebust@hammerspace.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-NFS Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-nfs/0 linux-nfs/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-nfs linux-nfs/ https://lore.kernel.org/linux-nfs \ linux-nfs@vger.kernel.org public-inbox-index linux-nfs Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-nfs AGPL code for this site: git clone https://public-inbox.org/public-inbox.git