Hi Filipe, thank you for your review. On Jan 17, 2022 / 17:08, Filipe Manana wrote: > On Mon, Jan 17, 2022 at 09:57:05AM +0900, Shin'ichiro Kawasaki wrote: > > Test quota disable during btrfs balance and confirm it does not cause > > kernel hang. This is a regression test for the problem reported to > > linux-btrfs list [1]. The hang was recreated using the test case and > > memory backed null_blk device with 5GB size as the scratch device. > > > > [1] https://lore.kernel.org/linux-btrfs/20220115053012.941761-1-shinichiro.kawasaki@xxxxxxx/ > > > > Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@xxxxxxx> > > --- > > tests/btrfs/255 | 42 ++++++++++++++++++++++++++++++++++++++++++ > > tests/btrfs/255.out | 2 ++ > > 2 files changed, 44 insertions(+) > > create mode 100755 tests/btrfs/255 > > create mode 100644 tests/btrfs/255.out > > > > diff --git a/tests/btrfs/255 b/tests/btrfs/255 > > new file mode 100755 > > index 00000000..16b682ca > > --- /dev/null > > +++ b/tests/btrfs/255 > > @@ -0,0 +1,42 @@ > > +#! /bin/bash > > +# SPDX-License-Identifier: GPL-2.0 > > +# Copyright (c) 2022 Western Digital Corporation or its affiliates. > > +# > > +# FS QA Test No. btrfs/255 > > +# > > +# Confirm that disabling quota during balance does not hang > > +# > > +. ./common/preamble > > +_begin_fstest auto qgroup > > Should have "balance" as well. Yes, will add it. > > > + > > +# real QA test starts here > > +_supported_fs btrfs > > +_require_scratch > > + > > +_scratch_mkfs >> $seqres.full 2>&1 > > +_scratch_mount > > + > > +# Fill 40% of the device or 2GB > > +fill_percent=40 > > +max_fillsize=$((2*1024*1024*1024)) > > If the test requires some minimum size, than it should call > > _require_scratch_size <size in KB> This test case does not have its specific minimum size requirement. The hang was observed even with a device which has btrfs minimum size 109MB. > > Also please make it a bit more readable by adding a single space before > and after each *, i.e. 2 * 1024 * 1024 ... instead of 2*1024*1024. > > > + > > +devsize=$(($(_get_device_size $SCRATCH_DEV) * 512)) > > +fillsize=$((devsize * fill_percent / 100)) > > +((fillsize > max_fillsize)) && fillsize=$max_fillsize > > + > > +fs=$((4096*1024)) > > Same here. > > > +for ((i=0; i * fs < fillsize; i++)); do > > And here (i = 0 vs i=0). Will reflect the comments above. > > > + dd if=/dev/zero of=$SCRATCH_MNT/file.$i bs=$fs count=1 \ > > + >> $seqres.full 2>&1 > > +done > > +echo 3 > /proc/sys/vm/drop_caches > > Why the drop_caches? Please add a comment explaining why it is needed. I've noticed that this drop cache is not required. I referred btrfs/115 for quota enable/disable test which has the drop_cache, and added it to this new test case without clear reason. The hang can be recreated without this drop_cache. Will remove it. > > > + > > +# Run btrfs balance and quota enable/disable in parallel > > +_run_btrfs_balance_start $SCRATCH_MNT >> $seqres.full & > > +$BTRFS_UTIL_PROG quota enable $SCRATCH_MNT > > +$BTRFS_UTIL_PROG quota disable $SCRATCH_MNT > > This seems very timing sensitive. > It would be a better stress test if we do the enable/disable in a loop, > say 10 or 20 iterations, while another process keeps running balance in > parallel and then is killed after the main process finishes the loop of > enable/disable quotas. Thanks. Will implement this idea to v2. -- Best Regards, Shin'ichiro Kawasaki
