Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp34821pxj; Wed, 16 Jun 2021 19:32:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwVKDRIQtrplxKgL90GX+Xbryo2EqKM7STYNGog2ACXnJlwSRcSdRARiDHy/RrCvqSWr0o7 X-Received: by 2002:a17:907:3e04:: with SMTP id hp4mr2585401ejc.473.1623897147351; Wed, 16 Jun 2021 19:32:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623897147; cv=none; d=google.com; s=arc-20160816; b=y8z9c6xNyv49WV4yqUFzOkgKPh+sy9NvGc4DcJ51eMzzEUAi/4KzEvcl5Ov7inghwB GvKsqKoIvwdUSJDpSLDI0bvVa+DIRgMtuX/7EYVqXM8TqxgvPMZPkep7rgkagncgZBVM jmlLMnhTydpE2Mb35FKtPUTLCNT0SAwgz0o4mMqZlns1jFRpR++NR/KCwIMtG1aEs/o2 n797ycsoBvZybBuzDZLtrph279gF4Cvh0aNbcWBWJrJWIN5ZpKVeBUdKgJCbq/8eAekl HvCNMfXbBqx8OI9e5xwZXwxdns++GFci7SYE3aebQDwiEk1EWudfRO+g99fv9JnwSevO wDOQ== 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=QW+hCe1c8o9MCwx9s0Zp3zybR/LZRnpW9CQwpSNIEIk=; b=x/QH2fTzs6oflLicM1LtKHX5CTwCnYb3J3E/VZgsbXtR3fY6XJ7I5NvM1RiOIu8aOM qpnJsVHw9DKjFjVDwAmsks8p6XSfWeoQmmPjWq0OMPKlnX0yYDsXZw9vhe4zHqxzTq2b cnFo/lgJEYYfZDOMHJwFzHJAmHibqzYeASK08QDCb+vtHqSTQaxq0s7aTD0qCvnBAp3P Z0ob9y6l3DtYmxQ2kIbQrhsQajkfVart3Mwde+0BNEB1fEwCEaPq/CfPxnC52PRWqHFb fX7u2g7Zi2H2AYFVomhQvIs5uBNFBDKVZ8QLehgUnl/Xix4C+H1RvvJjda+BZCG613kW gzAg== 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 j20si4204485edp.274.2021.06.16.19.32.04; Wed, 16 Jun 2021 19:32: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 S230390AbhFPW5s (ORCPT + 99 others); Wed, 16 Jun 2021 18:57:48 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:57265 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S229602AbhFPW5s (ORCPT ); Wed, 16 Jun 2021 18:57:48 -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 15GMtW1L022032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 16 Jun 2021 18:55:32 -0400 Received: by cwcc.thunk.org (Postfix, from userid 15806) id 08A4E15C3CB8; Wed, 16 Jun 2021 18:55:32 -0400 (EDT) Date: Wed, 16 Jun 2021 18:55:31 -0400 From: "Theodore Ts'o" To: Gao Xiang Cc: Trond Myklebust , "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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Thu, Jun 17, 2021 at 01:51:04AM +0800, Gao Xiang wrote: > > Considering the original XFS regression report [1], I think > underlayfs blksize may still be needed. And binary search to get the > maximum attr value may be another new case for this as well. Or > alternatively just add by block size to do a trip test. > > Although I have no idea if we can just skip the case when testing with > NFS. If getting underlayfs blksize is unfeasible, I think we might > skip such case for now since nfs blksize is not useful for generic/486. > > [1] https://bugzilla.kernel.org/show_bug.cgi?id=199119 I've looked at the original XFS regression size, and I don't see why using the underlaying blocksize matters at all. This is especially true if you look at the comment in the test, and the commit which fixed the bug. All that is needed for the xfs regression test is to start with a small xattr, and replace it with a large xattr. The blocksize is really irrelevant. - Ted