From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Anatoly Pugachev <matorola@gmail.com>
Cc: fstests <fstests@vger.kernel.org>, linux-xfs@vger.kernel.org
Subject: Re: [fstests] hardcoded values in common/rc for xfs (and probably others)
Date: Fri, 20 Oct 2017 10:05:58 -0700 [thread overview]
Message-ID: <20171020170558.GY4755@magnolia> (raw)
In-Reply-To: <CADxRZqwUfeGJOxsdEyaOHHJPmQUp8sNkxQdZPOKjyEejeZXMmA@mail.gmail.com>
On Fri, Oct 20, 2017 at 07:52:31PM +0300, Anatoly Pugachev wrote:
> Hello!
>
> While running generic/012 on xfs filesystem created on sparc64 linux
> (pagesize 8k) with "mkfs.xfs -b size=8192 /dev/vdiskb1" (but not with
> the default mkfs.xfs which will use 4k block size) , I'm getting the
> following output:
>
> root@ttip:xfstests-dev# cat local.config
> export TEST_DIR=/testvol
> export TEST_DEV=/dev/vdiskb1
> export SCRATCH_DEV_POOL="/dev/loop0 /dev/loop1 /dev/loop2"
> export SCRATCH_MNT=/1/scratch
> export MKFS_OPTIONS="-m reflink=1"
>
> root@ttip:xfstests-dev# mkfs.xfs -b size=8192 -m reflink=1 -f /dev/vdiskb1
> meta-data=/dev/vdiskb1 isize=512 agcount=4, agsize=983008 blks
> = sectsz=8192 attr=2, projid32bit=1
> = crc=1 finobt=1, sparse=0,
> rmapbt=0, reflink=1
> data = bsize=8192 blocks=3932032, imaxpct=25
> = sunit=0 swidth=0 blks
> naming =version 2 bsize=8192 ascii-ci=0 ftype=1
> log =internal log bsize=8192 blocks=2160, version=2
> = sectsz=8192 sunit=1 blks, lazy-count=1
> realtime =none extsz=8192 blocks=0, rtextents=0
>
> root@ttip:xfstests-dev# ./check generic/012
> FSTYP -- xfs (debug)
> PLATFORM -- Linux/sparc64 ttip 4.14.0-rc5
> MKFS_OPTIONS -- -f -m reflink=1 /dev/loop0
> MOUNT_OPTIONS -- /dev/loop0 /1/scratch
>
> generic/012 2s ... [not run] xfs_io fcollapse failed (old kernel/wrong
> fs/bad args?)
> Not run: generic/012
> Passed all 0 tests
>
> root@ttip:xfstests-dev# xfs_io -V
> xfs_io version 4.13.1
>
>
> debugging it, comes from the following xfs_io command:
>
> root@ttip:xfstests-dev# mount /dev/vdiskb1 /testvol/
> root@ttip:xfstests-dev# /opt/xfsprogs/sbin/xfs_io -i -F -f -c "pwrite
> 0 20k" -c fsync -c "fcollapse 4k 8k" /testvol/248329.xfs_io 2>&1
> wrote 20480/20480 bytes at offset 0
> 20 KiB, 3 ops; 0.0000 sec (95.741 MiB/sec and 14705.8824 ops/sec)
> fallocate: Invalid argument
>
>
> While chatting in #xfs irc channel, Darrick told that there is should
> not be hardcoded values (like 4k for fcollapse) in generic/012, but it
> comes from _require_xfs_io_command() from common/rc, quote:
>
> 19:19 < djwong> anyway... fcollapse (and finsert) both requires that
> the offset/length arguments are block-aligned
> 19:19 < djwong> hence you can't fcollapse starting at 4k on an fs with 8k blocks
>
> And it's not only generic/012, it fails generic/0{16,17,21,22} (and
> probably more) as well.
>
> Can someone look into this issue?
Does the following xfstests patch help?
--D
diff --git a/common/punch b/common/punch
index c4ed261..5648bd8 100644
--- a/common/punch
+++ b/common/punch
@@ -341,13 +341,26 @@ _test_generic_punch()
testfile=$6
multiple=1
+ # This routine was originally written for fallocate modes that
+ # don't have alignment requirements so the (sort of) hardcoded
+ # 4k offsets didn't matter. fcollapse and finsert require
+ # block-aligned arguments, so increase $multiple until we get
+ # to the file's minimum data block size.
+ case "$zero_cmd" in
+ "fcollapse"|"finsert")
+ touch $testfile
+ bs=$(_get_file_block_size $testfile)
+ test "$bs" -gt 4096 && multiple=$((bs / 4096))
+ ;;
+ esac
+
#
# If we are testing collapse range, we increare all the offsets of this
# test by a factor of 4. We do this because unlike punch, collapse
# range also decreases the size of file hence require bigger offsets.
#
if [ "$zero_cmd" == "fcollapse" ]; then
- multiple=4
+ multiple=$((multiple * 4))
fi
_4k="$((multiple * 4))k"
diff --git a/common/rc b/common/rc
index fe68d67..b585016 100644
--- a/common/rc
+++ b/common/rc
@@ -2063,8 +2063,8 @@ _require_xfs_io_command()
param_checked=1
;;
"fpunch" | "fcollapse" | "zero" | "fzero" | "finsert" | "funshare")
- testio=`$XFS_IO_PROG -F -f -c "pwrite 0 20k" -c "fsync" \
- -c "$command 4k 8k" $testfile 2>&1`
+ testio=`$XFS_IO_PROG -F -f -c "pwrite 0 256k" -c "fsync" \
+ -c "$command 64k 128k" $testfile 2>&1`
;;
"fiemap")
testio=`$XFS_IO_PROG -F -f -c "pwrite 0 20k" -c "fsync" \
next prev parent reply other threads:[~2017-10-20 17:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-20 16:52 [fstests] hardcoded values in common/rc for xfs (and probably others) Anatoly Pugachev
2017-10-20 17:05 ` Darrick J. Wong [this message]
2017-10-20 19:56 ` Anatoly Pugachev
2017-10-21 0:32 ` Darrick J. Wong
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=20171020170558.GY4755@magnolia \
--to=darrick.wong@oracle.com \
--cc=fstests@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=matorola@gmail.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).