public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Chandan Babu R <chandanrlinux@gmail.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: fstests@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 08/11] xfs: Check for extent overflow when moving extent from cow to data fork
Date: Wed, 18 Nov 2020 10:50:28 +0530	[thread overview]
Message-ID: <3004185.drFshOy15W@garuda> (raw)
In-Reply-To: <20201114004232.GI9695@magnolia>

On Saturday 14 November 2020 6:12:32 AM IST Darrick J. Wong wrote:
> On Fri, Nov 13, 2020 at 04:57:00PM +0530, Chandan Babu R wrote:
> > This test verifies that XFS does not cause inode fork's extent count to
> > overflow when writing to a shared extent.
> > 
> > Signed-off-by: Chandan Babu R <chandanrlinux@gmail.com>
> > ---
> >  tests/xfs/528     | 87 +++++++++++++++++++++++++++++++++++++++++++++++
> >  tests/xfs/528.out |  8 +++++
> >  tests/xfs/group   |  1 +
> >  3 files changed, 96 insertions(+)
> >  create mode 100755 tests/xfs/528
> >  create mode 100644 tests/xfs/528.out
> > 
> > diff --git a/tests/xfs/528 b/tests/xfs/528
> > new file mode 100755
> > index 00000000..0d39f05e
> > --- /dev/null
> > +++ b/tests/xfs/528
> > @@ -0,0 +1,87 @@
> > +#! /bin/bash
> > +# SPDX-License-Identifier: GPL-2.0
> > +# Copyright (c) 2020 Chandan Babu R.  All Rights Reserved.
> > +#
> > +# FS QA Test 528
> > +#
> > +# Verify that XFS does not cause inode fork's extent count to overflow when
> > +# writing to a shared extent.
> > +seq=`basename $0`
> > +seqres=$RESULT_DIR/$seq
> > +echo "QA output created by $seq"
> > +
> > +here=`pwd`
> > +tmp=/tmp/$$
> > +status=1	# failure is the default!
> > +trap "_cleanup; exit \$status" 0 1 2 3 15
> > +
> > +_cleanup()
> > +{
> > +	cd /
> > +	rm -f $tmp.*
> > +}
> > +
> > +# get standard environment, filters and checks
> > +. ./common/rc
> > +. ./common/filter
> > +. ./common/reflink
> > +. ./common/inject
> > +
> > +# remove previous $seqres.full before test
> > +rm -f $seqres.full
> > +
> > +# real QA test starts here
> > +
> > +_supported_fs xfs
> > +_require_scratch
> > +_require_scratch_reflink
> > +_require_xfs_debug
> > +_require_xfs_io_command "reflink"
> > +_require_xfs_io_error_injection "reduce_max_iextents"
> > +
> > +echo "* Write to shared extent"
> > +
> > +echo "Format and mount fs"
> > +_scratch_mkfs_sized $((512 * 1024 * 1024)) >> $seqres.full
> > +_scratch_mount >> $seqres.full
> > +
> > +bsize=$(_get_block_size $SCRATCH_MNT)
> 
> Now that we're playing with regular files again -- should this be
> _get_file_block_size ?  I think the same question applies to patches 2,
> 3, and 4, and perhaps the next one too.
> 
> (Note that regular files can have cluster sizes that aren't the same as
> the fs block size if I set MKFS_OPTIONS="-d rtinherit=1 -r extsize=64k".)

Patch 2 computes the size of the rt volume as a function of the bitmap
inode. The data associated with bitmap inode is stored in the regular
filesystem space. Hence filesystem block size is the appropriate choice here.
The same applies to quota inode extent count overflow test.

The test included in the next patch requires reflink to be enabled. Hence
filesystem block size is the correct choice.

For the other tests that you have mentioned and also for the fstress test I
will use _get_file_block_size().

> 
> --D
> 
> > +
> > +srcfile=${SCRATCH_MNT}/srcfile
> > +dstfile=${SCRATCH_MNT}/dstfile
> > +
> > +nr_blks=15
> > +
> > +echo "Create a \$srcfile having an extent of length $nr_blks blocks"
> > +xfs_io -f -c "pwrite -b $((nr_blks * bsize))  0 $((nr_blks * bsize))" \
> > +       -c fsync $srcfile  >> $seqres.full
> > +
> > +echo "Share the extent with \$dstfile"
> > +xfs_io -f -c "reflink $srcfile" $dstfile >> $seqres.full
> > +
> > +echo "Inject reduce_max_iextents error tag"
> > +xfs_io -x -c 'inject reduce_max_iextents' $SCRATCH_MNT
> > +
> > +echo "Buffered write to every other block of \$dstfile's shared extent"
> > +for i in $(seq 1 2 $((nr_blks - 1))); do
> > +	xfs_io -f -c "pwrite $((i * bsize)) $bsize" -c fsync $dstfile \
> > +	       >> $seqres.full 2>&1
> > +	[[ $? != 0 ]] && break
> > +done
> > +
> > +ino=$(stat -c "%i" $dstfile)
> > +
> > +_scratch_unmount >> $seqres.full
> > +
> > +echo "Verify \$dstfile's extent count"
> > +
> > +nextents=$(_scratch_get_iext_count $ino data || \
> > +		_fail "Unable to obtain inode fork's extent count")
> > +if (( $nextents > 10 )); then
> > +	echo "Extent count overflow check failed: nextents = $nextents"
> > +fi
> > +
> > +# success, all done
> > +status=0
> > +exit
> > + 
> > diff --git a/tests/xfs/528.out b/tests/xfs/528.out
> > new file mode 100644
> > index 00000000..8666488b
> > --- /dev/null
> > +++ b/tests/xfs/528.out
> > @@ -0,0 +1,8 @@
> > +QA output created by 528
> > +* Write to shared extent
> > +Format and mount fs
> > +Create a $srcfile having an extent of length 15 blocks
> > +Share the extent with $dstfile
> > +Inject reduce_max_iextents error tag
> > +Buffered write to every other block of $dstfile's shared extent
> > +Verify $dstfile's extent count
> > diff --git a/tests/xfs/group b/tests/xfs/group
> > index 627813fe..c85aac6b 100644
> > --- a/tests/xfs/group
> > +++ b/tests/xfs/group
> > @@ -525,3 +525,4 @@
> >  525 auto quick attr
> >  526 auto quick dir hardlink symlink
> >  527 auto quick
> > +528 auto quick reflink
> 


-- 
chandan




  reply	other threads:[~2020-11-18  5:20 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-13 11:26 [PATCH 00/11] xfs: Tests to check for inode fork extent count overflow detection Chandan Babu R
2020-11-13 11:26 ` [PATCH 01/11] common/xfs: Add a helper to get an inode fork's extent count Chandan Babu R
2020-11-14  0:10   ` Darrick J. Wong
2020-11-13 11:26 ` [PATCH 02/11] xfs: Check for extent overflow when trivally adding a new extent Chandan Babu R
2020-11-14  0:24   ` Darrick J. Wong
2020-11-17 14:12     ` Chandan Babu R
2020-11-18  2:30       ` Darrick J. Wong
2020-11-18  4:09         ` Chandan Babu R
2020-11-13 11:26 ` [PATCH 03/11] " Chandan Babu R
2020-11-14  0:18   ` Darrick J. Wong
2020-11-17 14:22     ` Chandan Babu R
2020-11-13 11:26 ` [PATCH 04/11] xfs: Check for extent overflow when punching a hole Chandan Babu R
2020-11-14  0:28   ` Darrick J. Wong
2020-11-17 14:26     ` Chandan Babu R
2020-11-13 11:26 ` [PATCH 05/11] xfs: Check for extent overflow when adding/removing xattrs Chandan Babu R
2020-11-14  0:34   ` Darrick J. Wong
2020-11-17 14:30     ` Chandan Babu R
2020-11-13 11:26 ` [PATCH 06/11] xfs: Check for extent overflow when adding/removing dir entries Chandan Babu R
2020-11-14  0:37   ` Darrick J. Wong
2020-11-17 14:50     ` Chandan Babu R
2020-11-13 11:26 ` [PATCH 07/11] xfs: Check for extent overflow when writing to unwritten extent Chandan Babu R
2020-11-14  0:39   ` Darrick J. Wong
2020-11-17 15:15     ` Chandan Babu R
2020-11-13 11:27 ` [PATCH 08/11] xfs: Check for extent overflow when moving extent from cow to data fork Chandan Babu R
2020-11-14  0:42   ` Darrick J. Wong
2020-11-18  5:20     ` Chandan Babu R [this message]
2020-11-13 11:27 ` [PATCH 09/11] xfs: Check for extent overflow when remapping an extent Chandan Babu R
2020-11-14  0:43   ` Darrick J. Wong
2020-11-13 11:27 ` [PATCH 10/11] xfs: Check for extent overflow when swapping extents Chandan Babu R
2020-11-14  0:08   ` Darrick J. Wong
2020-11-17 15:35     ` Chandan Babu R
2020-11-18  2:23       ` Darrick J. Wong
2020-11-13 11:27 ` [PATCH 11/11] xfs: Stress test with with bmap_alloc_minlen_extent error tag enabled Chandan Babu R
2020-11-14  0:06   ` Darrick J. Wong
2020-11-17 15:24     ` Chandan Babu R
2020-11-13 11:29 ` [PATCH 00/11] xfs: Tests to check for inode fork extent count overflow detection Chandan Babu R

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=3004185.drFshOy15W@garuda \
    --to=chandanrlinux@gmail.com \
    --cc=darrick.wong@oracle.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /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