Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp34615pxj; Wed, 16 Jun 2021 19:32:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzyU1FBq30M7snxv5tdcUI5YiflsKg3pqKy6JbRtlX4IGpDC6Q50lBDi0wmG3eTe2NPgxSg X-Received: by 2002:a05:6e02:111:: with SMTP id t17mr1851634ilm.216.1623897123428; Wed, 16 Jun 2021 19:32:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623897123; cv=none; d=google.com; s=arc-20160816; b=S1CyzSoDYphXCkgKy66wWXGWeXG/8tdKmN2EcpYQ7H0/d4Q18sV29GRokE1nIz8oxa rnvvUHRa6YJ7+GJt4sXoYgNF0LAUWLoL3e1WitqekIpwsXcIninBgfjdwoODTzxUcLKo TvHCdG0G/bdRsowtTdH7ymrqHzGTeXpZZpNun8VSBkl6Esfzy59k2RJI51n0lZrGT6fB Y1aQc52asdyf9h6oDn0Q6u9qdrlOlkTzYUz8RAkfR/YHgHJZVRAFGB0b3YY6h/htTeuv fqC4F+DkY0fgAlp0Ca0yPlvT7zyFpMLxxdjT7Nbd/ICkWoFQgxrWS43KkiadvhPLr4GE EalQ== 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=SV0Do+r3PVZG6u5Ioh/IfF6WNtMgzeyHoRCm997HwAI=; b=B8uTN0RdyGsPOtZ8jfCDzqFMf9fvyRTmI+G7HYoJrnM0YUmTBGNy57cM4X0vmKYOYE lY5KsYCaepuRYvtAeb1PyjgSWKK82ErsgyQ+flQsCvSBZGo3ctxYmO0Bcz30nT+9Ancl vTpqay1EDRfw4rYHhg39iFtvGsxvQbxh6bSRMGJqelUdQxLngz1HR51RF4oAL0fI6VG/ aPERv21Qt/fLSj4dFygjcjx6HKJbabWATi0Bp/wadaCZp9WVUIlNasA739WwKvInzuxP MMwr53M6R1zi6OP62LIUpZemYs+EFBRI3AO6fES5B19TQmlAf20n0EVQBb2O/F/A+r+8 jYLw== 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 y28si4154415iox.1.2021.06.16.19.31.46; Wed, 16 Jun 2021 19:32:03 -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 S229614AbhFPWx7 (ORCPT + 99 others); Wed, 16 Jun 2021 18:53:59 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:56881 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S229616AbhFPWx6 (ORCPT ); Wed, 16 Jun 2021 18:53:58 -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 15GMpZDA020903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 16 Jun 2021 18:51:36 -0400 Received: by cwcc.thunk.org (Postfix, from userid 15806) id 4851215C3CB8; Wed, 16 Jun 2021 18:51:35 -0400 (EDT) Date: Wed, 16 Jun 2021 18:51:35 -0400 From: "Theodore Ts'o" To: Frank van der Linden Cc: Trond Myklebust , "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> <20210616171708.GA24636@dev-dsk-fllinden-2c-d7720709.us-west-2.amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210616171708.GA24636@dev-dsk-fllinden-2c-d7720709.us-west-2.amazon.com> Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Wed, Jun 16, 2021 at 05:17:08PM +0000, Frank van der Linden wrote: > > The problem here for xfstests is how to define the 'correct' behavior > across all filesystems so that there's a clean pass/fail, as long > as these inconsistencies exist. Note that the original xfstest in question is to check what happens when you have a pre-existing xattr with a small (16 byte) value, and replacing (overwriting) the xattr with a large (but valid) value. The problem was that generic/486 was using the preferred size for efficient I/O size as the "block" size, and then using a percentage of this "block" size as the arbitrary "large xattr size". It was not about the error codes being returned, which is a bit confusing, and for which different man pages (attr_set and setxattr) are differently incomplete. That's really a different issue, and the fact that different file systems can use different error codes is not necessarily something that we need to rationalize, in particular for file systems like NFS where the error codes returned are not entirely under the control of the NFS client or server code. Cheers, - Ted