Files
apfstests/tests/btrfs/102
T
Filipe Manana 8c16b061f7 btrfs: make all btrfs tests that exercise balance use _run_btrfs_balance_start()
In btrfs-progs v4.10 we had a behaviour change where starting a balance
operation without any filters results in a delay of 10 seconds and a
warning is printed to stdout that warns that a full balance is about to
be made and that it can be a slow operation. The new flag '--full-balance'
was added in that release to avoid the 10 seconds delay and the warning
message.

Our existing helper _run_btrfs_balance_start() uses that new balance flag
if we are running a btrfs-progs version that has it, to avoid that 10
seconds wait.

Make all existing btrfs tests that trigger balance operations use the
_run_btrfs_balance_start() helper, so that we avoid wasting time and
speed up some of the tests. In particular test btrfs/014 is now about 10x
faster and tests btrfs/060 to btrfs/064 3 to 5 times faster (depending
on the fsstress random load).

Besides speeding up many tests that do balance operations it also fixes
functional problems:

1) Since btrfs-progs v4.10 the test case btrfs/014 got broken, because
   its purpose is to run balance and snapshot creation in parallel,
   and that wasn't happening anymore because all snapshots were being
   created during the 10 seconds delay of the first balance operation,
   so balance and snapshot creation was being serialized instead of
   running in parallel.

   Fixing this test to avoid the 10 seconds delay immediately
   exposes a regression that went into kernel 5.7-rc1 which is fixed
   by the following commit

   aec7db3b13a0 ("btrfs: fix setting last_trans for reloc roots")

2) Test cases btrfs/060 to btrfs/064 now spend much more time running
   fsstress, balance and other operations in parallel, there's no
   longer intervals of 10 seconds where balance is not running
   concurrently with those other operations, making the tests a lot
   more useful again.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2020-04-20 00:40:59 +08:00

65 lines
2.2 KiB
Bash
Executable File

#! /bin/bash
# SPDX-License-Identifier: GPL-2.0
# Copyright (C) 2015 SUSE Linux Products GmbH. All Rights Reserved.
#
# FSQA Test No. 102
#
# Regression test for an ENOSPC issue when attempting to write to a file in
# a filesystem without any data block groups allocated.
#
seq=`basename $0`
seqres=$RESULT_DIR/$seq
echo "QA output created by $seq"
tmp=/tmp/$$
status=1 # failure is the default!
trap "_cleanup; exit \$status" 0 1 2 3 15
_cleanup()
{
rm -f $tmp.*
}
# get standard environment, filters and checks
. ./common/rc
. ./common/filter
# real QA test starts here
_supported_fs btrfs
_supported_os Linux
_require_scratch
rm -f $seqres.full
_scratch_mkfs >>$seqres.full 2>&1
# Mount our filesystem without space caches enabled so that we do not get any
# space used from the initial data block group that mkfs creates (space caches
# used space from data block groups).
_scratch_mount "-o nospace_cache"
# Need an fs with at least 2Gb to make sure mkfs.btrfs does not create an fs
# using mixed block groups (used both for data and metadata). We really need
# to have dedicated block groups for data to reproduce the issue and mkfs.btrfs
# defaults to mixed block groups only for small filesystems (up to 1Gb).
_require_fs_space $SCRATCH_MNT $((2 * 1024 * 1024))
# Run balance with the purpose of deleting the unused data block group that
# mkfs created. We could also wait for the background kthread to automatically
# delete the unused block group, but we do not have a way to make it run and
# wait for it to complete, so just do a balance instead of some unreliable sleep
_run_btrfs_balance_start -dusage=0 $SCRATCH_MNT >> $seqres.full
# Now unmount the filesystem, mount it again (either with or with space caches
# enabled, it does not matter to trigger the problem) and attempt to create a
# file with some data - this used to fail with ENOSPC because there were no
# data block groups when the filesystem was mounted and the data space info
# object was marked as full when initialized (because it had 0 total bytes),
# which prevented the file write path from attempting to allocate a data block
# group and fail immediately with ENOSPC.
_scratch_cycle_mount
echo "hello world" > $SCRATCH_MNT/foobar
echo "Silence is golden"
status=0
exit