Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp639037pxj; Wed, 16 Jun 2021 10:09:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJysv6IHuPSA2Xi9oRp/YKxvGlwWkqLo/sZ7YcSGPDd6IQslWPB4b7pqlKRbMhlFEJfWwjjv X-Received: by 2002:a92:7b01:: with SMTP id w1mr492701ilc.100.1623863367878; Wed, 16 Jun 2021 10:09:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623863367; cv=none; d=google.com; s=arc-20160816; b=E1cDsjgxkUMUqT9r9ez9YibFfsEagfdYOArhiCvLaqisU0/xAJ5Ekqumq4T6EWZWTH vRP353sX3kHMIVdgeOybHquqlQNWF8xGr3q1/4GQhNyxQSP40adp0L5Zqw6tvjFWPWsk 1IBd4/seAzjMBPIdwqgf9NHPpldryJhvA+8frIBkjloSgAX3gbS/mYgUv8Cv/XiF3//N yT0FSj24FeyBzQqZABOKlq6BEpxAoTEgXEJuDNJAzHqPYr3filZs3X84FNVdil5kEqMR q27FmrXQlhEHOdq44B86kYJDnJ/famxQ+x/WcOkmFC2mKHBfjSd7rgik0A4d5mQJgWNi kCkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=O4/HO9/2w8cmA9hCB+uo/MHNF/UJ8cnNXaJ4oMYjmwI=; b=gw++3GQLKcpnXnKGvAP6ZIdTZeQiZHAHowSWio8ruyYWJRhB8PtBo958+hxfcgQaLu RoaXkifMJDyvHSUFEaMNMEe5GcXS0hWv6eUApU0SwSG18+UcAixn8ypsfpMocfnUQsUd HmwEj2bJEHUoobWsg6ZIqZA0an3jIeMGn13Euw4AeAgi7W3FbRTtDo2CWHZ5CGDSb2cB VbgvPza6d7KfUhRpeOOOsYvPXbHYbvpUr/NBafybNUTYfvLtTXfeMP2eLsCYyC9Y1CMK umPfytfD8p0358+7If7fHJvn1Dkqe2s174hKpHl4BYEap2utBFFYqpFo5R97zrWi8HSM opmg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g1si3550330ild.63.2021.06.16.10.09.05; Wed, 16 Jun 2021 10:09:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230167AbhFPRLG (ORCPT + 99 others); Wed, 16 Jun 2021 13:11:06 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:60920 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S230083AbhFPRLG (ORCPT ); Wed, 16 Jun 2021 13:11:06 -0400 Received: from cwcc.thunk.org (pool-72-74-133-215.bstnma.fios.verizon.net [72.74.133.215]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 15GH8lKW010194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 16 Jun 2021 13:08:49 -0400 Received: by cwcc.thunk.org (Postfix, from userid 15806) id 0DA7615C3CB8; Wed, 16 Jun 2021 13:08:47 -0400 (EDT) Date: Wed, 16 Jun 2021 13:08:47 -0400 From: "Theodore Ts'o" To: Trond Myklebust Cc: "hsiangkao@linux.alibaba.com" , "linux-nfs@vger.kernel.org" , "joseph.qi@linux.alibaba.com" , "linux-kernel@vger.kernel.org" , "anna.schumaker@netapp.com" Subject: Re: [PATCH] nfs: set block size according to pnfs_blksize first Message-ID: References: <1623847469-150122-1-git-send-email-hsiangkao@linux.alibaba.com> <4898aa11dc26396c13bbc3d8bf18c13efe4d513a.camel@hammerspace.com> <2c14b63eacf1742bb0bcd2ae02f2d7005f7682d8.camel@hammerspace.com> <80199ffaf89fc5ef2ad77245f9a5e75beed2dc37.camel@hammerspace.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80199ffaf89fc5ef2ad77245f9a5e75beed2dc37.camel@hammerspace.com> Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org 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