All of lore.kernel.org
 help / color / mirror / Atom feed
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" \

  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 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.