All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eryu Guan <guan@eryu.me>
To: Ritesh Harjani <riteshh@linux.ibm.com>
Cc: fstests@vger.kernel.org, linux-ext4@vger.kernel.org,
	Theodore Ts'o <tytso@mit.edu>,
	"Darrick J . Wong" <djwong@kernel.org>
Subject: Re: [PATCHv2 7/9] generic/620: Use _mkfs_dev_blocksized to use 4k bs
Date: Sun, 8 Aug 2021 21:32:48 +0800	[thread overview]
Message-ID: <YQ/dAFFDLp0edZUl@desktop> (raw)
In-Reply-To: <20210803050622.yh2wn2fhzxn4jjbv@riteshh-domain>

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.

> > >
> > > <error log with 64k bs>
> > > 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 <riteshh@linux.ibm.com>
> > > ---
> > >  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

  reply	other threads:[~2021-08-08 13:33 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-21  5:27 [PATCHv2 0/9] xfstests: 64K blocksize related fixes Ritesh Harjani
2021-07-21  5:27 ` [PATCHv2 1/9] ext4/003: Fix this test on 64K platform for dax config Ritesh Harjani
2021-07-21  5:27 ` [PATCHv2 2/9] ext4/027: Correct the right code of block and inode bitmap Ritesh Harjani
2021-07-21  5:27 ` [PATCHv2 3/9] ext4/306: Add -b blocksize parameter too to avoid failure with DAX config Ritesh Harjani
2021-07-21  5:27 ` [PATCHv2 4/9] ext4/022: exclude this test for dax config on 64KB pagesize platform Ritesh Harjani
2021-07-21  5:27 ` [PATCHv2 5/9] generic/031: Fix the test case for 64k blocksize config Ritesh Harjani
2021-08-01 16:00   ` Eryu Guan
2021-08-03  5:00     ` Ritesh Harjani
2021-08-08 12:36       ` Eryu Guan
2021-07-21  5:27 ` [PATCHv2 6/9] common/rc: Add _mkfs_dev_blocksized functionality Ritesh Harjani
2021-07-21  5:28 ` [PATCHv2 7/9] generic/620: Use _mkfs_dev_blocksized to use 4k bs Ritesh Harjani
2021-08-01 16:03   ` Eryu Guan
2021-08-03  5:06     ` Ritesh Harjani
2021-08-08 13:32       ` Eryu Guan [this message]
2021-07-21  5:28 ` [PATCHv2 8/9] common/attr: Cleanup end of line whitespaces issues Ritesh Harjani
2021-07-21  5:28 ` [PATCHv2 9/9] common/attr: Reduce MAX_ATTRS to leave some overhead for 64K blocksize Ritesh Harjani
2021-08-01 16:05 ` [PATCHv2 0/9] xfstests: 64K blocksize related fixes Eryu Guan

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=YQ/dAFFDLp0edZUl@desktop \
    --to=guan@eryu.me \
    --cc=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=riteshh@linux.ibm.com \
    --cc=tytso@mit.edu \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.