public inbox for fstests@vger.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: fstests@vger.kernel.org
Cc: darrick.wong@oracle.com, Theodore Ts'o <tytso@mit.edu>
Subject: [PATCH] generic/466: be more precise about which block sizes to use
Date: Mon, 11 Dec 2017 12:27:42 -0500	[thread overview]
Message-ID: <20171211172742.3490-1-tytso@mit.edu> (raw)

The test previously blindly tried block sizes from 512 to 65536 and
relied on mkfs to fail.  This is problematic for a number of file
systems.  For example, when testing btrfs, _scratch_mkfs_sized simply
ignores the blocksize, so the test will pointlessly run the same test
multiple times.  For ext4, when encryption is enabled, the only block
size which is supported is the page size.

So define two new functions _fs_min_blocksize and _fs_max_blocksize,
and use it so that generic/466 will only try using the block sizes
that will work.

Signed-off-by: Theodore Ts'o <tytso@mit.edu>
---
 common/rc         | 23 +++++++++++++++++++++++
 tests/generic/466 |  6 +++++-
 2 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/common/rc b/common/rc
index 59d4b961..7aa747ad 100644
--- a/common/rc
+++ b/common/rc
@@ -1067,6 +1067,29 @@ _scratch_mkfs_blocksized()
     esac
 }
 
+_fs_min_blocksize()
+{
+    case $FSTYP in
+    ext4)
+	if echo "$MOUNT_OPTIONS" | grep -q "test_dummy_encryption"; then
+	    get_page_size
+	else
+            echo 1024
+	fi
+       ;;
+    btrfs)
+	get_page_size
+	;;
+    *)
+	echo 512
+    esac
+}
+
+_fs_max_blocksize()
+{
+    get_page_size
+}
+
 _scratch_resvblks()
 {
 	case $FSTYP in
diff --git a/tests/generic/466 b/tests/generic/466
index 07f24a74..a1d944d3 100755
--- a/tests/generic/466
+++ b/tests/generic/466
@@ -54,7 +54,11 @@ unset MKFS_OPTIONS
 
 echo "Starting test" > $seqres.full
 devsize=$(blockdev --getsize64 $SCRATCH_DEV)
-for blocksize in 512 1024 2048 4096 8192 16384 32768 65536; do
+min_blocksize=$(_fs_min_blocksize)
+max_blocksize=$(_fs_max_blocksize)
+
+for (( blocksize = min_blocksize ; blocksize <= max_blocksize ;
+       blocksize = blocksize * 2)); do
 	echo "+ Format blocksize $blocksize and mount" >> $seqres.full
 	_scratch_unmount > /dev/null 2>&1
 	# Try to format and mount with the given blocksize.  If they don't
-- 
2.11.0.rc0.7.gbe5a750


             reply	other threads:[~2017-12-11 17:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-11 17:27 Theodore Ts'o [this message]
2017-12-13 17:36 ` [PATCH] generic/466: be more precise about which block sizes to use Darrick J. Wong
2017-12-31 18:45   ` Theodore Ts'o
2018-01-02 20:36     ` Darrick J. Wong
2018-01-05  2:12       ` Darrick J. Wong
2018-01-05  3:28         ` Theodore Ts'o
2018-01-07 15:24           ` 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=20171211172742.3490-1-tytso@mit.edu \
    --to=tytso@mit.edu \
    --cc=darrick.wong@oracle.com \
    --cc=fstests@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