From: "Darrick J. Wong" <djwong@kernel.org>
To: Theodore Ts'o <tytso@mit.edu>
Cc: fstests@vger.kernel.org, linux-xfs@vger.kernel.org,
leah.rumancik@gmail.com
Subject: Re: xfs/076 takes a long long time testing with a realtime volume
Date: Fri, 5 Nov 2021 19:08:04 -0700 [thread overview]
Message-ID: <20211106020804.GU24307@magnolia> (raw)
In-Reply-To: <YYXhNip3PctJAaDY@mit.edu>
On Fri, Nov 05, 2021 at 09:58:14PM -0400, Theodore Ts'o wrote:
> 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?
Does adding:
_xfs_force_bdev data $SCRATCH_MNT
right after _scratch_mount make the performance problem go away? Sparse
inodes and realtime are a supported configuration.
--D
> 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
next prev parent reply other threads:[~2021-11-06 2:08 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 ` xfs/076 takes a long long time testing with a realtime volume Theodore Ts'o
2021-11-06 2:08 ` Darrick J. Wong [this message]
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=20211106020804.GU24307@magnolia \
--to=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=leah.rumancik@gmail.com \
--cc=linux-xfs@vger.kernel.org \
--cc=tytso@mit.edu \
/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