Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Anand Jain <anand.jain@oracle.com>
To: Eryu Guan <guan@eryu.me>
Cc: fstests@vger.kernel.org, linux-btrfs@vger.kernel.org,
	josef@toxicpanda.com
Subject: Re: [PATCH v2] btrfs/254: test cleaning up of the stale device
Date: Wed, 5 Jan 2022 12:19:24 +0800	[thread overview]
Message-ID: <d7d823c3-30ce-e6ff-7599-1f404a82d4ff@oracle.com> (raw)
In-Reply-To: <YdRvu1guqLdmm4/5@desktop>



On 05/01/2022 00:03, Eryu Guan wrote:
> On Tue, Jan 04, 2022 at 07:25:20PM +0800, Anand Jain wrote:
>>
>> Gentle ping? More below.
> 
> It's already been merged in last update.

  Ah.  I forgot to refresh my ws. Thanks.

>> On 20/12/2021 19:06, Anand Jain wrote:
>>>
>>>
>>> On 19/12/2021 22:02, Eryu Guan wrote:
>>>> On Sat, Dec 11, 2021 at 02:14:41AM +0800, Anand Jain wrote:
>>>>> Recreating a new filesystem or adding a device to a mounted the
>>>>> filesystem
>>>>> should remove the device entries under its previous fsid even when
>>>>> confused with different device paths to the same device.
>>>>>
>>>>> Fixed by the kernel patch (in the ml):
>>>>>     btrfs: harden identification of the stale device
>>>>>
>>>>> Signed-off-by: Anand Jain <anand.jain@oracle.com>
>>>>
>>>> I was testing with v5.16-rc2 kernel, which should not contain the kernel
>>>> fix, but test still passed for me, I was testing with three loop devices
>>>> as SCRATCH_DEV_POOL, and all default mkfs & mount options
>>>>
>>>> SECTION       -- btrfs
>>>> RECREATING    -- btrfs on /dev/mapper/testvg-lv1
>>>> FSTYP         -- btrfs
>>>> PLATFORM      -- Linux/x86_64 fedoravm 5.16.0-rc2 #22 SMP PREEMPT
>>>> Mon Nov 29 00:54:26 CST 2021
>>>> MKFS_OPTIONS  -- /dev/loop0
>>>> MOUNT_OPTIONS -- /dev/loop0 /mnt/scratch
>>>> btrfs/254 5s ...  5s
>>>> Ran: btrfs/254
>>>> Passed all 1 tests
>>>>
>>>> Anything wrong with my setup?
>>>>
>>>> And if tested with lv devices as SCRATCH_DEV_POOL
>>>>
>>>> SCRATCH_DEV_POOL="/dev/mapper/testvg-lv2 /dev/mapper/testvg-lv3
>>>> /dev/mapper/testvg-lv4 /dev/mapper/testvg-lv5
>>>> /dev/mapper/testvg-lv6"
>>>>
>>>> I got the following test failure
>>>>
>>>>    QA output created by 254
>>>> +ERROR: cannot unregister device '/dev/mapper/254-test': No such
>>>> file or directory
>>>>    Label: none  uuid: <UUID>
>>>>           Total devices <NUM> FS bytes used <SIZE>
>>>>           devid <DEVID> size <SIZE> used <SIZE> path SCRATCH_DEV
>>>>
>>>> Maybe we should use _require_scratch_nolvm as well?
>>>>
>>>
>>
>>> The test case is inconsistent because the systemd-udev block device scan
>>> interferes with the test script. There is no way to disable the
>>> systemd-udev scan (that I could find).
>>>
>>> The same inconsistency (due to race with systemd-udev scan) would
>>> persist with/without lvm.
>>>
>>> So when the race fails, the test case is successful to reproduce the
>>> issue. As you saw in the 2nd iteration.
>>
>>
>> There isn't any approach to stop the test case from racing with the device
>> scan, so reproducing the issue is inconsistent. As we have had some success
>> so IMO this test case can still integrate, it will help to verify the kernel
> 
> Agreed.
> 
>> fix on some systems.
>>
>> More below.
>>
>>>
>>> Any suggestions?
>>>
>>> Thanks, Anand
>>>
>>>
>>>>> ---
>>>>> v2: Add kernel patch title in the test case
>>>>>       Redirect device add output to /dev/null (avoids tirm message)
>>>>>       Use the lv path for mkfs and the dm path for the device add
>>>>>        so that now path used in udev scan should match with what
>>>>>        we already have in the kernel memory.
>>>>>
>>>>> -       _mkfs_dev $uuid -draid1 -mraid1 $dmdev $scratch_dev2
>>>>> +       _mkfs_dev $uuid -draid1 -mraid1 $lvdev $scratch_dev2
>>>>>           # Add device should free the device under $uuid in the kernel.
>>>>> -       $BTRFS_UTIL_PROG device add -f $lvdev $seq_mnt > /dev/null 2>&1
>>>>> +       $BTRFS_UTIL_PROG device add -f $dmdev $seq_mnt > /dev/null 2>&1
>>>>>
>>>>>
>>>>>    tests/btrfs/254     | 113 ++++++++++++++++++++++++++++++++++++++++++++
>>>>>    tests/btrfs/254.out |   6 +++
>>>>>    2 files changed, 119 insertions(+)
>>>>>    create mode 100755 tests/btrfs/254
>>>>>    create mode 100644 tests/btrfs/254.out
>>>>>
>>>>> diff --git a/tests/btrfs/254 b/tests/btrfs/254
>>>>> new file mode 100755
>>>>> index 000000000000..b70b9d165897
>>>>> --- /dev/null
>>>>> +++ b/tests/btrfs/254
>>>>> @@ -0,0 +1,113 @@
>>>>> +#! /bin/bash
>>>>> +# SPDX-License-Identifier: GPL-2.0
>>>>> +# Copyright (c) 2021 Anand Jain. All Rights Reserved.
>>>>> +# Copyright (c) 2021 Oracle. All Rights Reserved.
>>>>> +#
>>>>> +# FS QA Test No. 254
>>>>> +#
>>>>> +# Test if the kernel can free the stale device entries.
>>>>> +#
>>>>> +# Tests bug fixed by the kernel patch:
>>>>> +#    btrfs: harden identification of the stale device
>>>>> +#
>>>>> +. ./common/preamble
>>>>> +_begin_fstest auto quick
>>>>> +
>>>>> +# Override the default cleanup function.
>>>>> +node=$seq-test
>>>>> +cleanup_dmdev()
>>>>> +{
>>>>> +    _dmsetup_remove $node
>>>>> +}
>>>>> +
>>>>> +_cleanup()
>>>>> +{
>>>>> +    cd /
>>>>> +    rm -f $tmp.*
>>>>> +    rm -rf $seq_mnt > /dev/null 2>&1
>>>>> +    cleanup_dmdev
>>>>
>>>> Should wipefs in cleanup as well, otherwise test fails with non-unique
>>>> UUID
>>>>
>>>> -Label: none  uuid: <UUID>
>>>> -       Total devices <NUM> FS bytes used <SIZE>
>>>> -       devid <DEVID> size <SIZE> used <SIZE> path SCRATCH_DEV
>>>> -       *** Some devices missing
>>
>>>> +ERROR: non-unique UUID: 12345678-1234-1234-1234-123456789abc
>>
>>
>>   We don't need non-unique UUID. I have fixed this in v3.
> 
> Then would you please help patch the existing test?

  Yep. I am sending a new patch for that.

> And we should add 'volume' group as well?

  It can be in the volume group, so added.

Thanks, Anand

> Thanks,
> Eryu
> 
>>
>> Thanks,
>> Anand
>>
>>
>>>> +btrfs-progs v5.4
>>>> +See http://btrfs.wiki.kernel.org for more information.
>>>>
>>>> Thanks,
>>>> Eryu
>>>>
>>>>> +}
>>>>> +
>>>>> +# Import common functions.
>>>>> +. ./common/filter
>>>>> +. ./common/filter.btrfs
>>>>> +
>>>>> +# real QA test starts here
>>>>> +_supported_fs btrfs
>>>>> +_require_scratch_dev_pool 3
>>>>> +_require_block_device $SCRATCH_DEV
>>>>> +_require_dm_target linear
>>>>> +_require_btrfs_forget_or_module_loadable
>>>>> +_require_scratch_nocheck
>>>>> +_require_command "$WIPEFS_PROG" wipefs
>>>>> +
>>>>> +_scratch_dev_pool_get 3
>>>>> +
>>>>> +setup_dmdev()
>>>>> +{
>>>>> +    # Some small size.
>>>>> +    size=$((1024 * 1024 * 1024))
>>>>> +    size_in_sector=$((size / 512))
>>>>> +
>>>>> +    table="0 $size_in_sector linear $SCRATCH_DEV 0"
>>>>> +    _dmsetup_create $node --table "$table" || \
>>>>> +        _fail "setup dm device failed"
>>>>> +}
>>>>> +
>>>>> +# Use a known it is much easier to debug.
>>>>> +uuid="--uuid 12345678-1234-1234-1234-123456789abc"
>>>>> +lvdev=/dev/mapper/$node
>>>>> +
>>>>> +seq_mnt=$TEST_DIR/$seq.mnt
>>>>> +mkdir -p $seq_mnt
>>>>> +
>>>>> +test_forget()
>>>>> +{
>>>>> +    setup_dmdev
>>>>> +    dmdev=$(realpath $lvdev)
>>>>> +
>>>>> +    _mkfs_dev $uuid $dmdev
>>>>> +
>>>>> +    # Check if we can un-scan using the mapper device path.
>>>>> +    $BTRFS_UTIL_PROG device scan --forget $lvdev
>>>>> +
>>>>> +    # Cleanup
>>>>> +    $WIPEFS_PROG -a $lvdev > /dev/null 2>&1
>>>>> +    $BTRFS_UTIL_PROG device scan --forget
>>>>> +
>>>>> +    cleanup_dmdev
>>>>> +}
>>>>> +
>>>>> +test_add_device()
>>>>> +{
>>>>> +    setup_dmdev
>>>>> +    dmdev=$(realpath $lvdev)
>>>>> +    scratch_dev2=$(echo $SCRATCH_DEV_POOL | awk '{print $2}')
>>>>> +    scratch_dev3=$(echo $SCRATCH_DEV_POOL | awk '{print $3}')
>>>>> +
>>>>> +    _mkfs_dev $scratch_dev3
>>>>> +    _mount $scratch_dev3 $seq_mnt
>>>>> +
>>>>> +    _mkfs_dev $uuid -draid1 -mraid1 $lvdev $scratch_dev2
>>>>> +
>>>>> +    # Add device should free the device under $uuid in the kernel.
>>>>> +    $BTRFS_UTIL_PROG device add -f $dmdev $seq_mnt > /dev/null 2>&1
>>>>> +
>>>>> +    _mount -o degraded $scratch_dev2 $SCRATCH_MNT
>>>>> +
>>>>> +    # Check if the missing device is shown.
>>>>> +    $BTRFS_UTIL_PROG filesystem show -m $SCRATCH_MNT | \
>>>>> +                    _filter_btrfs_filesystem_show
>>>>> +
>>>>> +    $UMOUNT_PROG $seq_mnt
>>>>> +    _scratch_unmount
>>>>> +    cleanup_dmdev
>>>>> +}
>>>>> +
>>>>> +test_forget
>>>>> +test_add_device
>>>>> +
>>>>> +_scratch_dev_pool_put
>>>>> +
>>>>> +status=0
>>>>> +exit
>>>>> diff --git a/tests/btrfs/254.out b/tests/btrfs/254.out
>>>>> new file mode 100644
>>>>> index 000000000000..20819cf5140c
>>>>> --- /dev/null
>>>>> +++ b/tests/btrfs/254.out
>>>>> @@ -0,0 +1,6 @@
>>>>> +QA output created by 254
>>>>> +Label: none  uuid: <UUID>
>>>>> +    Total devices <NUM> FS bytes used <SIZE>
>>>>> +    devid <DEVID> size <SIZE> used <SIZE> path SCRATCH_DEV
>>>>> +    *** Some devices missing
>>>>> +
>>>>> -- 
>>>>> 2.27.0

      reply	other threads:[~2022-01-05  4:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-10 18:14 [PATCH v2] btrfs/254: test cleaning up of the stale device Anand Jain
2021-12-19 14:02 ` Eryu Guan
2021-12-20 11:06   ` Anand Jain
2022-01-04 11:25     ` Anand Jain
2022-01-04 16:03       ` Eryu Guan
2022-01-05  4:19         ` Anand Jain [this message]

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=d7d823c3-30ce-e6ff-7599-1f404a82d4ff@oracle.com \
    --to=anand.jain@oracle.com \
    --cc=fstests@vger.kernel.org \
    --cc=guan@eryu.me \
    --cc=josef@toxicpanda.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