Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp1943043pxt; Sun, 8 Aug 2021 06:34:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzPPNdq9OQmGEsYI1BNobkeeBfiIomtBc3LImJr4kBqaKTUaSAPB0rVOSzkZszWCkYcdM17 X-Received: by 2002:a17:906:e0ce:: with SMTP id gl14mr18520923ejb.168.1628429646531; Sun, 08 Aug 2021 06:34:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628429646; cv=none; d=google.com; s=arc-20160816; b=ErQ9ax8AH9/xhHmfT3oDhJVym7AbSJsEGpsaAtPCypH9LtX/2yADZXDDMtwznyWVq8 2q5KHBAcXlxeeLC7sCxkhBv7g6D9nC6knmRoFPfuDybXpgi3ejEfd9Iw9zpDHEdfdZ97 1Ug2RRBSp5vTLs2GZKG1oZZWJDT7SWkoxYmf/Jl3PY0e6Gu8BMdVOiUPrXxsRtbHcEW7 Yd6YIVnwCqTBOo1K9YieAbNNsXIaayYI8fp6JF8F1vXdKFwHdE2oS9mv0F/YOF6A5qig uv9vFW+CHS9zicbUPrdMXktqc3lL6HWOkoGq5uYy2LD2cocBIA1/x/9omQK3TEoBvNdW TEuw== 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=SXWRih4KEa6X7d8uRjRvnqmWBko3ycaF6hn23ckRysg=; b=NRjWKaqd6cXXKdVSA2nR5eYq3wm+uBwi2EeqYxkTXfpIAapcOR2NVO4jPM8hGyGJ65 d6WMzAFixfS4pFYZ9BQvsPw1UUuoOj+Blh1AhaP5bqcSZPeH0CyIPNytjlnT1+GBNl3a PRj0zih9mnzbyeKlPNV30FmWVEX6m1rJsvXK99bZDgPZTS+urIKluXj7sblwnMxnNkC3 Qik1pKDHzXQjSuO4TNlYXBjfXRNaXYvWapk1aCyiViERKYU+VfDKR/YpFJE7BUUBg8LY KcmI0FZZvmGAXK/1kx8J7EG03uomebqV8zxeCOXL90iW7+qzF5nlzkEfbX0PJhR+f1Sp XzXg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-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 p7si14804654edq.323.2021.08.08.06.33.31; Sun, 08 Aug 2021 06:34:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-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-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231218AbhHHNdV (ORCPT + 99 others); Sun, 8 Aug 2021 09:33:21 -0400 Received: from out20-73.mail.aliyun.com ([115.124.20.73]:37046 "EHLO out20-73.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230505AbhHHNdL (ORCPT ); Sun, 8 Aug 2021 09:33:11 -0400 X-Alimail-AntiSpam: AC=CONTINUE;BC=0.07502286|-1;CH=green;DM=|CONTINUE|false|;DS=CONTINUE|ham_regular_dialog|0.265791-0.0208945-0.713315;FP=0|0|0|0|0|-1|-1|-1;HT=ay29a033018047198;MF=guan@eryu.me;NM=1;PH=DS;RN=5;RT=5;SR=0;TI=SMTPD_---.Kx179PM_1628429568; Received: from localhost(mailfrom:guan@eryu.me fp:SMTPD_---.Kx179PM_1628429568) by smtp.aliyun-inc.com(10.147.41.158); Sun, 08 Aug 2021 21:32:48 +0800 Date: Sun, 8 Aug 2021 21:32:48 +0800 From: Eryu Guan To: Ritesh Harjani Cc: fstests@vger.kernel.org, linux-ext4@vger.kernel.org, Theodore Ts'o , "Darrick J . Wong" Subject: Re: [PATCHv2 7/9] generic/620: Use _mkfs_dev_blocksized to use 4k bs Message-ID: References: <20210803050622.yh2wn2fhzxn4jjbv@riteshh-domain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210803050622.yh2wn2fhzxn4jjbv@riteshh-domain> Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Tue, Aug 03, 2021 at 10:36:22AM +0530, Ritesh Harjani wrote: > On 21/08/02 12:03AM, Eryu Guan wrote: > > On Wed, Jul 21, 2021 at 10:58:00AM +0530, Ritesh Harjani wrote: > > > ext4 with 64k blocksize (passed by user config) fails with below error for > > > this given test which requires dmhugedisk. Since this test anyways only > > > requires 4k bs, so use _mkfs_dev_blocksized() to fix this. I don't see how this test always requires 4k blocksize, 1k blocksized xfs also passes the test. > > > > > > > > > mkfs.ext4: Input/output error while writing out and closing file system Is this a bug in mkfs.ext4 or expected error (unsupported config)? If it's an expected error, it'd be better to explain it in commit log as well. > > > > > > Signed-off-by: Ritesh Harjani > > > --- > > > tests/generic/620 | 4 +++- > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > diff --git a/tests/generic/620 b/tests/generic/620 > > > index b052376f..444e682d 100755 > > > --- a/tests/generic/620 > > > +++ b/tests/generic/620 > > > @@ -42,7 +42,9 @@ sectors=$((2*1024*1024*1024*17)) > > > chunk_size=128 > > > > > > _dmhugedisk_init $sectors $chunk_size > > > -_mkfs_dev $DMHUGEDISK_DEV > > > + > > > +# Use 4k blocksize. > > > +_mkfs_dev_blocksized 4096 $DMHUGEDISK_DEV > > > > We run the test by forcing 4k blocksize, which could be tested in 4k > > blocksize setup. Maybe it's another case that should _notrun in 64k > > blocksize setup. > > So for testing that, first I should mkfs and mount a scratch device with the > passed mount/mkfs options and then see if the blocksize passed is 64K, if yes > I should _notrun this case. > > Isn't the current approach of (_mkfs_dev_blocksized 4096) is better then above > approach? If the test always requires 4k blocksize, forcing creating a 4k blocksize filesystem doesn't increase any test coverage, I don't see any point introducing a new _mkfs_dev_blocksized helper just to do so. And even if we decide to force 4k blocksize config, I think it'd be better to update _scratch_mkfs_blocksized() to take device as argument, like what _check_scratch_fs() does, so we don't duplicate all the code to create fs with specified blocksize. Thanks, Eryu > > -ritesh > > > Thanks, > > Eryu > > > > > _mount $DMHUGEDISK_DEV $SCRATCH_MNT || _fail "mount failed for $DMHUGEDISK_DEV $SCRATCH_MNT" > > > testfile=$SCRATCH_MNT/testfile-$seq > > > > > > -- > > > 2.31.1