All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: fstests@vger.kernel.org, linux-xfs@vger.kernel.org,
	leah.rumancik@gmail.com
Subject: xfs/076 takes a long long time testing with a realtime volume
Date: Fri, 5 Nov 2021 21:58:14 -0400	[thread overview]
Message-ID: <YYXhNip3PctJAaDY@mit.edu> (raw)
In-Reply-To: <YYVo8ZyKpy4Di0pK@mit.edu>

After committing some exclusions into my test runner framework (see
below), I tested a potential fix to xfs/076 which disables the
real-time volume when creating the scratch volume.  Should I send it
as a formal patch to fstests?

diff --git a/tests/xfs/076 b/tests/xfs/076
index eac7410e..5628c08f 100755
--- a/tests/xfs/076
+++ b/tests/xfs/076
@@ -60,6 +60,7 @@ _require_xfs_io_command "falloc"
 _require_xfs_io_command "fpunch"
 _require_xfs_sparse_inodes
 
+unset SCRATCH_RTDEV
 _scratch_mkfs "-d size=50m -m crc=1 -i sparse" |
 	_filter_mkfs > /dev/null 2> $tmp.mkfs
 . $tmp.mkfs	# for isize

						- Ted

For why this is needed, see the commit description below:

commit c41ae1cc0b21eafd2858541c0bc195f951c0726c
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Fri Nov 5 20:46:19 2021 -0400

    test-appliance: exclude xfs/076 from the realtime configs
    
    The xfs/076 test takes two minutes on a normal xfs file system (e.g.,
    a normal 4k block size file system).  However, when there is a
    real-time volume attached, this test takes over 80 minutes.  The
    reason for this seems to be because the test is spending a lot more
    time failing to create files due to missing directories.  Compare:
    
    root@xfstests-2:~# ls -sh /results/xfs/results-4k/xfs/076.full
    48K /results/xfs/results-4k/xfs/076.full
    root@xfstests-2:~# ls -sh /tmp/realtime-076.full
    25M /tmp/realtime-076.full
    
    and:
    
    root@xfstests-2:~# grep "cannot touch" /results/xfs/results-4k/xfs/076.full | wc -l
    656
    root@xfstests-2:~# grep "cannot touch" /tmp/realtime-076.full | wc -l
    327664
    
    The failures from 076.full look like this:
    
    touch: cannot touch '/xt-vdc/offset.21473722368/25659': No space left on device
    touch: cannot touch '/xt-vdc/offset.21473656832/0': No such file or directory
    touch: cannot touch '/xt-vdc/offset.21473591296/0': No such file or directory
    ...
    touch: cannot touch '/xt-vdc/offset.196608/0': No such file or directory
    touch: cannot touch '/xt-vdc/offset.131072/0': No such file or directory
    touch: cannot touch '/xt-vdc/offset.65536/0': No such file or directory
    touch: cannot touch '/xt-vdc/offset.0/0': No such file or directory
    
    What seems to be going on is that xfs/076 tries to create a small
    scratch file system --- but when we attach a real-time volume this
    balloons the available size of the file system.  Of course, that space
    can't be used for normal files.  As a result, xfs/076 is incorrectly
    estimating how many files it needs to create to fill the file system.
    
    I'm not sure what's the best way to fix this in the test; perhaps the
    test should forcibly unset SCRATCH_RTDEV environment variable before
    running _scratch_mkfs?  Anyway, for now, we'll just skip running
    xfs/076 for the xfs/realtime* configs.
    
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>

diff --git a/kvm-xfstests/test-appliance/files/root/fs/xfs/cfg/realtime.exclude b/kvm-xfstests/test-appliance/files/root/fs/xfs/cfg/realtime.exclude
index a9acba9c..bafce552 100644
--- a/kvm-xfstests/test-appliance/files/root/fs/xfs/cfg/realtime.exclude
+++ b/kvm-xfstests/test-appliance/files/root/fs/xfs/cfg/realtime.exclude
@@ -1,2 +1,7 @@
 # Normal configurations don't support dax
 -g dax
+
+# The xfs/076 test takes well over an hour (80 minutes using 100GB GCE
+# PD/SSD) when run with an external realtime device, which triggers
+# the ltm "test is stalled" failsafe which aborts the VM.
+xfs/076
diff --git a/kvm-xfstests/test-appliance/files/root/fs/xfs/cfg/realtime_28k_logdev.exclude b/kvm-xfstests/test-appliance/files/root/fs/xfs/cfg/realtime_28k_logdev.exclude
index a9acba9c..bafce552 100644
--- a/kvm-xfstests/test-appliance/files/root/fs/xfs/cfg/realtime_28k_logdev.exclude
+++ b/kvm-xfstests/test-appliance/files/root/fs/xfs/cfg/realtime_28k_logdev.exclude
@@ -1,2 +1,7 @@
 # Normal configurations don't support dax
 -g dax
+
+# The xfs/076 test takes well over an hour (80 minutes using 100GB GCE
+# PD/SSD) when run with an external realtime device, which triggers
+# the ltm "test is stalled" failsafe which aborts the VM.
+xfs/076
diff --git a/kvm-xfstests/test-appliance/files/root/fs/xfs/cfg/realtime_logdev.exclude b/kvm-xfstests/test-appliance/files/root/fs/xfs/cfg/realtime_logdev.exclude
index a9acba9c..bafce552 100644
--- a/kvm-xfstests/test-appliance/files/root/fs/xfs/cfg/realtime_logdev.exclude
+++ b/kvm-xfstests/test-appliance/files/root/fs/xfs/cfg/realtime_logdev.exclude
@@ -1,2 +1,7 @@
 # Normal configurations don't support dax
 -g dax
+
+# The xfs/076 test takes well over an hour (80 minutes using 100GB GCE
+# PD/SSD) when run with an external realtime device, which triggers
+# the ltm "test is stalled" failsafe which aborts the VM.
+xfs/076

  reply	other threads:[~2021-11-06  1:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-05 17:25 soft lockup in xfs/170 on a file system formatted with -m crc=0 Theodore Ts'o
2021-11-06  1:58 ` Theodore Ts'o [this message]
2021-11-06  2:08   ` xfs/076 takes a long long time testing with a realtime volume Darrick J. Wong
2021-11-06 16:43     ` Theodore Ts'o
2021-11-06  2:10 ` soft lockup in xfs/170 on a file system formatted with -m crc=0 Darrick J. Wong
2021-11-06 14:52   ` Theodore Ts'o

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=YYXhNip3PctJAaDY@mit.edu \
    --to=tytso@mit.edu \
    --cc=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=leah.rumancik@gmail.com \
    --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 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.