From: Chandan Rajendra <chandan@linux.vnet.ibm.com>
To: Dave Chinner <david@fromorbit.com>
Cc: fstests@vger.kernel.org, guaneryu@gmail.com,
darrick.wong@oracle.com, zlang@redhat.com,
linux-xfs@vger.kernel.org
Subject: Re: [PATCH V5 06/20] Fix xfs/139 to work with 64k block size
Date: Sat, 06 Oct 2018 12:21:22 +0530 [thread overview]
Message-ID: <3892653.Ddf5GiE5O6@localhost.localdomain> (raw)
In-Reply-To: <20181006003338.GC6311@dastard>
On Saturday, October 6, 2018 6:03:38 AM IST Dave Chinner wrote:
> On Mon, Sep 24, 2018 at 08:49:28PM +0530, Chandan Rajendra wrote:
> > For 64k block size, the agsize provided in the test causes mkfs.xfs to
> > fail due to insufficient log space. Hence this commit computes agsize
> > based on block size of the filesystem.
> >
> > Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
> > ---
> > tests/xfs/139 | 15 +++++++++------
> > tests/xfs/139.out | 8 ++++++--
> > 2 files changed, 15 insertions(+), 8 deletions(-)
> >
> > diff --git a/tests/xfs/139 b/tests/xfs/139
> > index 2a26635..c074273 100755
> > --- a/tests/xfs/139
> > +++ b/tests/xfs/139
> > @@ -34,17 +34,20 @@ _require_cp_reflink
> >
> > rm -f $seqres.full
> >
> > +_scratch_mkfs >/dev/null 2>&1
> > +_scratch_mount
> > +blksz=$(_get_file_block_size $SCRATCH_MNT)
> > +_scratch_unmount
> > +
> > echo "Format and mount"
> > -_scratch_mkfs -d agsize=$((32 * 1048576)) > $seqres.full 2>&1
> > +_scratch_mkfs -d agsize=$((8192 * $blksz)) > $seqres.full 2>&1
>
> This breaks 512 byte and 1k block size filesystems.
>
> $ head -3 139.full
> Invalid value 8388608 for -d agsize option. Value is too small.
> Usage: mkfs.xfs
> /* blocksize */ [-b size=num]
> $
>
> Minimum AG size is 16MB. There are more changes to other tests in
> this series that also demonstrate this regression.
Thanks for mentioning this fact about the minimum AG size. I will verify
all the tests once again.
Also, for xfs/139, 512 byte block size does not apply since reflink feature
requires CRC to be enabled. Nevertheless, I will make sure that mkfs.xfs
actually does succeed for other tests where 512 bytes block size is applicable.
--
chandan
next prev parent reply other threads:[~2018-10-06 13:51 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-24 15:19 [PATCH V5 00/20] Fix tests to work on non-4k block sized fs instances Chandan Rajendra
2018-09-24 15:19 ` [PATCH V5 01/20] Fix xfs/009 to work with 64k block size Chandan Rajendra
2018-09-24 15:19 ` [PATCH V5 02/20] xfs/050: Fix "Push past soft inode limit" case Chandan Rajendra
2018-09-24 15:19 ` [PATCH V5 03/20] Fix xfs/050 to work with 64k block size Chandan Rajendra
2018-09-24 15:19 ` [PATCH V5 04/20] Fix xfs/074 " Chandan Rajendra
2018-09-24 15:19 ` [PATCH V5 05/20] Fix xfs/127 " Chandan Rajendra
2018-09-24 15:19 ` [PATCH V5 06/20] Fix xfs/139 " Chandan Rajendra
2018-10-06 0:33 ` Dave Chinner
2018-10-06 6:51 ` Chandan Rajendra [this message]
2018-09-24 15:19 ` [PATCH V5 07/20] Fix xfs/140 " Chandan Rajendra
2018-09-24 15:19 ` [PATCH V5 08/20] Fix xfs/190 " Chandan Rajendra
2018-09-24 15:19 ` [PATCH V5 09/20] xfs/299: Fix "Push past soft inode limit" case Chandan Rajendra
2018-09-24 15:19 ` [PATCH V5 10/20] Fix xfs/299 to work with 64k block size Chandan Rajendra
2018-09-24 15:19 ` [PATCH V5 11/20] xfs/325: Inject free_extent error after CoW operation Chandan Rajendra
2018-09-24 15:19 ` [PATCH V5 12/20] Fix generic/102 to work with 64k block size Chandan Rajendra
2018-09-24 15:19 ` [PATCH V5 13/20] Fix generic/172 " Chandan Rajendra
2018-09-24 15:19 ` [PATCH V5 14/20] Filter fiemap output by FS " Chandan Rajendra
2018-09-24 15:19 ` [PATCH V5 15/20] Fix generic/177 to work with 64k " Chandan Rajendra
2018-09-24 15:19 ` [PATCH V5 16/20] Fix generic/230 " Chandan Rajendra
2018-09-24 15:19 ` [PATCH V5 17/20] Fix generic/235 " Chandan Rajendra
2018-09-24 15:19 ` [PATCH V5 18/20] Fix generic/459 " Chandan Rajendra
2018-09-24 15:19 ` [PATCH V5 19/20] Fix generic/018 " Chandan Rajendra
2018-09-24 15:19 ` [PATCH V5 20/20] Fix generic/108 " Chandan Rajendra
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=3892653.Ddf5GiE5O6@localhost.localdomain \
--to=chandan@linux.vnet.ibm.com \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=fstests@vger.kernel.org \
--cc=guaneryu@gmail.com \
--cc=linux-xfs@vger.kernel.org \
--cc=zlang@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).