From: "Theodore Ts'o" <tytso@mit.edu> To: Trond Myklebust <trondmy@hammerspace.com> Cc: "hsiangkao@linux.alibaba.com" <hsiangkao@linux.alibaba.com>, "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>, "joseph.qi@linux.alibaba.com" <joseph.qi@linux.alibaba.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "anna.schumaker@netapp.com" <anna.schumaker@netapp.com> Subject: Re: [PATCH] nfs: set block size according to pnfs_blksize first Date: Wed, 16 Jun 2021 13:08:47 -0400 [thread overview] Message-ID: <YMowH6STCondvzuJ@mit.edu> (raw) In-Reply-To: <80199ffaf89fc5ef2ad77245f9a5e75beed2dc37.camel@hammerspace.com> On Wed, Jun 16, 2021 at 03:14:17PM +0000, Trond Myklebust wrote: > > should we transform it to E2BIG instead (at least in NFS > > protocol)? but I'm still not sure that E2BIG is a valid return code for > > setxattr()... > > The setxattr() manpage appears to suggest ERANGE is the correct return > value here. > > ERANGE The size of name or value exceeds a filesystem-specific > limit. > > However I can't tell if ext4 and xfs ever do that. Ext4 will return ERANGE if the size of the xattr name is greater than 255 bytes. However, if there is no room to create the xattr --- for example there is no space to allocate a file system block, ext4 will return ENOSPC. Without the ea_inode feature, ext2 and ext4 use a single 4k block to store all extended attributes. So whether an xattr can be created is dependent on whether there is room in that 4k block. If there are too many xattrs, or the sum of the length of all the xattr names and values plus a certain amount of overhead exceeds 4k, it will return ENOSPC. > Furthermore, it looks as if the VFS is always returning E2BIG if > size > XATTR_SIZE_MAX. This is defined by the attr_set(3) man page, but not in the setxattr(2) man page. The set of errors are never intended to be exhaustive --- there are some tcp-related errors that probably can exposed to the caller when it is operating on a network-based file system, for example. But it would probably be a good idea to update the man pages so it's a bit clearer when E2BIG and ERANGE and ENOSPC mean. Cheers, - Ted
next prev parent reply other threads:[~2021-06-16 17:09 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-16 12:44 Gao Xiang 2021-06-16 13:47 ` Trond Myklebust 2021-06-16 14:06 ` Gao Xiang 2021-06-16 14:20 ` Trond Myklebust 2021-06-16 14:41 ` Gao Xiang 2021-06-16 15:14 ` Trond Myklebust 2021-06-16 17:08 ` Theodore Ts'o [this message] 2021-06-16 17:17 ` Frank van der Linden 2021-06-16 22:51 ` Theodore Ts'o 2021-06-16 16:14 ` Theodore Ts'o 2021-06-16 17:51 ` Gao Xiang 2021-06-16 18:51 ` Trond Myklebust 2021-06-16 22:55 ` Theodore Ts'o 2021-06-17 2:39 ` Gao Xiang 2021-06-17 13:08 ` Theodore Ts'o
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=YMowH6STCondvzuJ@mit.edu \ --to=tytso@mit.edu \ --cc=anna.schumaker@netapp.com \ --cc=hsiangkao@linux.alibaba.com \ --cc=joseph.qi@linux.alibaba.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-nfs@vger.kernel.org \ --cc=trondmy@hammerspace.com \ --subject='Re: [PATCH] nfs: set block size according to pnfs_blksize first' \ /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
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.