From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: Eryu Guan <eguan@redhat.com>, Jeff Mahoney <jeffm@suse.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>, <fstests@vger.kernel.org>
Subject: Re: [PATCH 1/2] btrfs/131: test for umount of read-only fs when quota rescan is paused
Date: Wed, 17 Aug 2016 16:59:11 +0800 [thread overview]
Message-ID: <fc7adfe0-bd8e-39ba-b47d-d54b29f40e47@cn.fujitsu.com> (raw)
In-Reply-To: <20160817084539.GS27776@eguan.usersys.redhat.com>
At 08/17/2016 04:45 PM, Eryu Guan wrote:
> On Tue, Aug 16, 2016 at 02:30:21PM -0400, Jeff Mahoney wrote:
>> Ensure that we can unmount a read-only file system when quota rescan
>> is paused from a previous read-write mount.
>>
>> If the kernel has a separate bug where we are returning early while
>> waiting for the rescan worker, we can use that to un-hang the test,
>> and report both errors.
>>
>> This issue is resolved by the following patch for the Linux kernel:
>> "btrfs: properly track when rescan worker is running"
>>
>> Signed-off-by: Jeff Mahoney <jeffm@suse.com>
>> ---
>> tests/btrfs/131 | 100 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>> tests/btrfs/131.out | 3 ++
>> tests/btrfs/group | 1 +
>> 3 files changed, 104 insertions(+)
>> create mode 100755 tests/btrfs/131
>> create mode 100644 tests/btrfs/131.out
>>
>> diff --git a/tests/btrfs/131 b/tests/btrfs/131
>> new file mode 100755
>> index 0000000..56c38a2
>> --- /dev/null
>> +++ b/tests/btrfs/131
>> @@ -0,0 +1,100 @@
>> +#! /bin/bash
>> +# FS QA Test 131
>> +#
>> +# Test for bug where read-only mounts will hang on umount when
>> +# a qgroup rescan was paused. This also tests whether that hung
>> +# umount can be unhung by trying to make use of a separate bug that
>> +# means we can interrupt the wait for the rescan worker. If that
>> +# happens, we report both errors.
>> +#
>> +#-----------------------------------------------------------------------
>> +# Copyright (c) 2016 SUSE. All Rights Reserved.
>> +#
>> +# This program is free software; you can redistribute it and/or
>> +# modify it under the terms of the GNU General Public License as
>> +# published by the Free Software Foundation.
>> +#
>> +# This program is distributed in the hope that it would be useful,
>> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
>> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> +# GNU General Public License for more details.
>> +#
>> +# You should have received a copy of the GNU General Public License
>> +# along with this program; if not, write the Free Software Foundation,
>> +# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
>> +#-----------------------------------------------------------------------
>> +#
>> +
>> +seq=`basename $0`
>> +seqres=$RESULT_DIR/$seq
>> +echo "QA output created by $seq"
>> +
>> +here=`pwd`
>> +tmp=/tmp/$$
>> +status=1 # failure is the default!
>> +trap "_cleanup; exit \$status" 0 1 2 3 15
>> +
>> +_cleanup()
>> +{
>> + cd /
>> + rm -f $tmp.*
>> +}
>> +
>> +# get standard environment, filters and checks
>> +. ./common/rc
>> +. ./common/filter
>> +
>> +# remove previous $seqres.full before test
>> +rm -f $seqres.full
>> +
>> +# real QA test starts here
>> +
>> +# Modify as appropriate.
>> +_supported_fs btrfs
>> +_supported_os Linux
>> +
>> +# We'll exit with a quota rescan paused
>> +_require_scratch_nocheck
>> +
>> +_require_btrfs
>> +BTRFS_DEBUG_TREE_PROG="`set_prog_path btrfs-debug-tree`"
>> +_require_command "$BTRFS_DEBUG_TREE_PROG" btrfs-debug-tree
>> +TIMEOUT_PROG="`set_prog_path timeout`"
>> +_require_command "$TIMEOUT_PROG" timeout
>
> The "set_prog_path" calls belong to common/config, we only need
> "_require_command" calls in test.
>
>> +
>> +rm -f $seqres.full
>> +_scratch_mkfs >>$seqres.full 2>&1
>> +
>> +_scratch_mount
>> +cp -aR /lib/modules/$(uname -r) $SCRATCH_MNT
>
> Consider populating the filesystem using _populate_fs or fsstress?
If only want to increase tree level, best solution is to create a lot of
small 2K files.
(Needs max_inline=2K incase user override it)
_populate_fs with -s 2048 is for this case.
If want normal files, -s 16384 would ensure it won't be inlined and
still small enough for quick population.
>
>> +
>> +# A qgroup rescan on an empty or small file system completes nearly
>> +# immediately. We need to ensure that it runs long enough that it will
>> +# be paused on umount. Snapshots slow down the rescan so we should see
>> +# the race without a lot of data. This is an arbitrary number that
>> +# works on a ramdisk so it should be sufficient for any storage.
>> +for n in $(seq 1 100); do
>> + _run_btrfs_util_prog subvolume snapshot $SCRATCH_MNT $SCRATCH_MNT/$n
>
> Use tab for indention.
>
>> +done
>> +_run_btrfs_util_prog quota enable $SCRATCH_MNT
>> +_scratch_unmount
>> +
>> +echo "read-write umount completed"
>> +
>> +# Confirm that the rescan is paused
>> +if ! $BTRFS_DEBUG_TREE_PROG $SCRATCH_DEV | \
>> + egrep -q 'flags ON|SCANNING|INCONSISTENT scan'; then
>> + echo "qgroup rescan not paused."
>> +fi
I'm a little concerned of this operation.
As debug-tree output can change at any time, since it doesn't expect it
to be used as a stable tool to exam some flag.
Although I don't have a better alternative though.
Thanks,
Qu
>> +_scratch_mount -r
>> +
>> +# If the bug exists, this will hang. If we can kill it, that's another bug.
>> +$TIMEOUT_PROG 10 umount $SCRATCH_MNT
>> +if test $? -eq 124 ; then
>> + echo "umount hung but was killed"
>
> I see this log with 4.8-rc1 kernel, is that expected?
>
> Thanks,
> Eryu
>
>> +fi
>> +echo "read-only umount completed"
>> +
>> +# success, all done
>> +status=0
>> +exit
>> diff --git a/tests/btrfs/131.out b/tests/btrfs/131.out
>> new file mode 100644
>> index 0000000..845a501
>> --- /dev/null
>> +++ b/tests/btrfs/131.out
>> @@ -0,0 +1,3 @@
>> +QA output created by 131
>> +read-write umount completed
>> +read-only umount completed
>> diff --git a/tests/btrfs/group b/tests/btrfs/group
>> index 6b29c05..929fa21 100644
>> --- a/tests/btrfs/group
>> +++ b/tests/btrfs/group
>> @@ -133,3 +133,4 @@
>> 128 auto quick send
>> 129 auto quick send
>> 130 auto clone send
>> +131 auto quick qgroup
>> --
>> 1.8.5.6
>>
>>
>> --
>> Jeff Mahoney
>> SUSE Labs
>> --
>> To unsubscribe from this list: send the line "unsubscribe fstests" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
next prev parent reply other threads:[~2016-08-17 8:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-16 18:30 [PATCH 1/2] btrfs/131: test for umount of read-only fs when quota rescan is paused Jeff Mahoney
2016-08-17 8:45 ` Eryu Guan
2016-08-17 8:59 ` Qu Wenruo [this message]
2016-08-19 19:20 ` Jeff Mahoney
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=fc7adfe0-bd8e-39ba-b47d-d54b29f40e47@cn.fujitsu.com \
--to=quwenruo@cn.fujitsu.com \
--cc=eguan@redhat.com \
--cc=fstests@vger.kernel.org \
--cc=jeffm@suse.com \
--cc=linux-btrfs@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;
as well as URLs for NNTP newsgroup(s).