All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ritesh Harjani <riteshh@linux.ibm.com>
To: Eryu Guan <guan@eryu.me>
Cc: fstests@vger.kernel.org, linux-ext4@vger.kernel.org,
	"Theodore Ts'o" <tytso@mit.edu>,
	"Darrick J . Wong" <djwong@kernel.org>,
	Dave Chinner <david@fromorbit.com>
Subject: Re: [PATCHv2 5/9] generic/031: Fix the test case for 64k blocksize config
Date: Tue, 3 Aug 2021 10:30:33 +0530	[thread overview]
Message-ID: <20210803050033.meopotfeooo6n4gu@riteshh-domain> (raw)
In-Reply-To: <YQbFDtq9aDA7Ql1j@desktop>

On 21/08/02 12:00AM, Eryu Guan wrote:
> On Wed, Jul 21, 2021 at 10:57:58AM +0530, Ritesh Harjani wrote:
> > This test fails with blocksize 64k since the test assumes 4k blocksize
> > in fcollapse param. This patch fixes that and also tests for 64k
> > blocksize.
> >
> > Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com>
> > ---
> >  tests/generic/031     | 14 +++++++++-----
> >  tests/generic/031.out | 16 ++++++++--------
> >  2 files changed, 17 insertions(+), 13 deletions(-)
> >
> > diff --git a/tests/generic/031 b/tests/generic/031
> > index 313ce9ff..11961c54 100755
> > --- a/tests/generic/031
> > +++ b/tests/generic/031
> > @@ -26,11 +26,16 @@ testfile=$SCRATCH_MNT/testfile
> >  _scratch_mkfs > /dev/null 2>&1
> >  _scratch_mount
> >
> > +# fcollapse need offset and len to be multiple of blocksize for filesystems
> > +# So let's make the offsets and len required for fcollapse multiples of 64K
> > +# so that it works for all configurations (including on dax on 64K page size
> > +# systems)
> > +fact=$((65536/4096))
> >  $XFS_IO_PROG -f \
> > -	-c "pwrite 185332 55756" \
> > -	-c "fcollapse 28672 40960" \
> > -	-c "pwrite 133228 63394" \
> > -	-c "fcollapse 0 4096" \
> > +	-c "pwrite $((185332*fact + 12)) $((55756*fact + 12))" \
>
> Where does this 12 come from?
A random number so that the offset and length are not bocksize aligned.
If you see the final .out file, you will see the offset of the writes
remains the same with and before this patch.

> And I'm wondering if this still reproduces the original bug.
I am not sure how to trigger this. I know that this test was intended for
bs < ps cases. If someone can help me / point me to the kernel fix for this,
I can try to reproduce the original bug too.

I found this link for this test patch series. Couldn't find the kernel fixes
link though.
https://www.spinics.net/lists/fstests/msg00340.html


>
> And looks like that the original test setups came from a specific
> fsstress or fsx run, and aimed to the specific bug, perhaps we could
> require the test with <= 4k block size, and _notrun in 64k case.

It would be good to know whether this code could trigger the original bug or
not. Then we need not make _notrun for 64k case.

>
> Thanks,
> Eryu
>
> > +	-c "fcollapse $((28672 * fact)) $((40960 * fact))" \
> > +	-c "pwrite $((133228 * fact + 12)) $((63394 * fact + 12))" \
> > +	-c "fcollapse 0 $((4096 * fact))" \
> >  $testfile | _filter_xfs_io
> >
> >  echo "==== Pre-Remount ==="
> > @@ -41,4 +46,3 @@ hexdump -C $testfile
> >
> >  status=0
> >  exit
> > -
> > diff --git a/tests/generic/031.out b/tests/generic/031.out
> > index 194bfa45..7dfcfe41 100644
> > --- a/tests/generic/031.out
> > +++ b/tests/generic/031.out
> > @@ -1,19 +1,19 @@
> >  QA output created by 031
> > -wrote 55756/55756 bytes at offset 185332
> > +wrote 892108/892108 bytes at offset 2965324
> >  XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> > -wrote 63394/63394 bytes at offset 133228
> > +wrote 1014316/1014316 bytes at offset 2131660
> >  XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> >  ==== Pre-Remount ===
> >  00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> >  *
> > -0001f860  00 00 00 00 00 00 00 00  00 00 00 00 cd cd cd cd  |................|
> > -0001f870  cd cd cd cd cd cd cd cd  cd cd cd cd cd cd cd cd  |................|
> > +001f86c0  00 00 00 00 00 00 00 00  00 00 00 00 cd cd cd cd  |................|
> > +001f86d0  cd cd cd cd cd cd cd cd  cd cd cd cd cd cd cd cd  |................|
> >  *
> > -0002fdc0
> > +002fdc18
> >  ==== Post-Remount ==
> >  00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> >  *
> > -0001f860  00 00 00 00 00 00 00 00  00 00 00 00 cd cd cd cd  |................|
> > -0001f870  cd cd cd cd cd cd cd cd  cd cd cd cd cd cd cd cd  |................|
> > +001f86c0  00 00 00 00 00 00 00 00  00 00 00 00 cd cd cd cd  |................|
> > +001f86d0  cd cd cd cd cd cd cd cd  cd cd cd cd cd cd cd cd  |................|
> >  *
> > -0002fdc0
> > +002fdc18
> > --
> > 2.31.1

  reply	other threads:[~2021-08-03  5:00 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 [this message]
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
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=20210803050033.meopotfeooo6n4gu@riteshh-domain \
    --to=riteshh@linux.ibm.com \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=guan@eryu.me \
    --cc=linux-ext4@vger.kernel.org \
    --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.