From: Anand Jain <anand.jain@oracle.com>
To: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Cc: linux-btrfs@vger.kernel.org, quwenruo@cn.fujitsu.com,
David Sterba <dsterba@suse.cz>
Subject: Re: [PATCH 1/2 v3 RESEND] Btrfs: device_list_add() should not update list when mounted
Date: Wed, 02 Jul 2014 00:31:57 +0800 [thread overview]
Message-ID: <53B2E27D.2030609@oracle.com> (raw)
In-Reply-To: <53B26066.1060505@cn.fujitsu.com>
Thanks for the commenting Wang.
inline below.
On 01/07/2014 15:16, Wang Shilong wrote:
> Hi Anand,
>
> Sorry for delay reply, more comments below:
>
> On 06/13/2014 12:26 PM, Anand Jain wrote:
>> From: Anand Jain <anand.jain@oracle.com>
>>
>> device_list_add() is called when user runs btrfs dev scan, which would
>> add
>> any btrfs device into the btrfs_fs_devices list.
>>
>> Now think of a mounted btrfs. And a new device which contains the a SB
>> from the mounted btrfs devices.
>>
>> In this situation when user runs btrfs dev scan, the current code would
>> just replace existing device with the new device.
>>
>> Which is to note that old device is neither closed nor gracefully
>> removed from the btrfs.
>>
>> The FS is still operational with the old bdev however the device name
>> is the btrfs_device is new which is provided by the btrfs dev scan.
>>
>> reproducer:
>>
>> devmgt[1] detach /dev/sdc
>>
>> replace the missing disk /dev/sdc
>>
>> btrfs rep start -f 1 /dev/sde /btrfs
>> Label: none uuid: 5dc0aaf4-4683-4050-b2d6-5ebe5f5cd120
>> Total devices 2 FS bytes used 32.00KiB
>> devid 1 size 958.94MiB used 115.88MiB path /dev/sde
>> devid 2 size 958.94MiB used 103.88MiB path /dev/sdd
>>
>> make /dev/sdc to reappear
>>
>> devmgt attach host2
>>
>> btrfs dev scan
>>
>> btrfs fi show -m
>> Label: none uuid: 5dc0aaf4-4683-4050-b2d6-5ebe5f5cd120^M
>> Total devices 2 FS bytes used 32.00KiB^M
>> devid 1 size 958.94MiB used 115.88MiB path /dev/sdc <- Wrong.
>> devid 2 size 958.94MiB used 103.88MiB path /dev/sdd
>>
>> since /dev/sdc has been replaced with /dev/sde, the /dev/sdc shouldn't be
>> part of the btrfs-fsid when it reappears. If user want it to be part
>> of it
>> then sys admin should be using btrfs device add instead.
>>
>> [1] github.com/anajain/devmgt.git
>>
>> Signed-off-by: Anand Jain <anand.jain@oracle.com>
>> ---
>> v2->v3: simpler commit and comment message
>> v1->v2: remove '---' in commit messages which conflict with git am
>>
>> fs/btrfs/volumes.c | 27 +++++++++++++++++++++++++++
>> 1 file changed, 27 insertions(+)
>>
>> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
>> index bb2cd66..56822f0 100644
>> --- a/fs/btrfs/volumes.c
>> +++ b/fs/btrfs/volumes.c
>> @@ -472,6 +472,7 @@ static noinline int device_list_add(const char *path,
>> device = __find_device(&fs_devices->devices, devid,
>> disk_super->dev_item.uuid);
>> }
>> +
> You add an extra line here.
>> if (!device) {
>> if (fs_devices->opened)
>> return -EBUSY;
>> @@ -497,6 +498,32 @@ static noinline int device_list_add(const char
>> *path,
>> device->fs_devices = fs_devices;
>> } else if (!device->name || strcmp(device->name->str, path)) {
>> + /*
>> + * When FS is already mounted.
>> + * 1. If you are here and if the device->name is NULL that means
>> + * this device was missing at time of FS mount.
>> + * 2. If you are here and if the device->name is different
>> from 'path'
>> + * that means either
>> + * a. The same device disappeared and reappeared with
>> different
>> + * name. or
>> + * b. The missing-disk-which-was-replaced, has
>> reappeared now.
>> + *
>> + * We must allow 1 and 2a above. But 2b would be a spurious and
>> + * unintentional.
>> + * Further in case of 1 and 2a above, the disk at 'path'
>> would have
>> + * missed some transaction when it was away and in case of 2a
>> + * the stale bdev has to be updated as well.
>> + * 2b must not be allowed at all time.
>> + */
>> +
>> + /*
>> + * As of now don't allow update to btrfs_fs_device through the
>> + * btrfs dev scan cli, after FS has been mounted.
>> + */
>> +
>> + if (fs_devices->opened)
>> + return -EBUSY;
>> +
> I agree we don't allow to update device list when mounted, i tested this
> patch, it worked but
Thanks for testing this patch set.
> it will output the following message:
>
> Scanning for Btrfs filesystems in '/dev/sdc'
> ERROR: unable to scan the device '/dev/sdc' - Device or resource busy
>
> I think this is a little confusing for common users. Maybe don't return
> error but output
> some log message into kernel buffer, better?
the Other choices are:
display the error only when specific device is used
by the user like 'btrfs dev scan /dev/sdc' And don't print busy /
invalid error when a system wide scan is used like 'btrfs dev scan'.
To achieve this we have to tweak btrfs-progs.
or put the error under the verbose option in the btrfs-progs.
> Thanks,
> Wang
>> name = rcu_string_strdup(path, GFP_NOFS);
>> if (!name)
>> return -ENOMEM;
>
> --
> 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:[~2014-07-01 16:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-13 4:26 [PATCH 1/2 v3 RESEND] Btrfs: device_list_add() should not update list when mounted Anand Jain
2014-06-13 4:26 ` [PATCH 2/2] btrfs: check generation as replace duplicates devid+uuid Anand Jain
2014-07-01 7:39 ` Wang Shilong
2014-07-01 7:16 ` [PATCH 1/2 v3 RESEND] Btrfs: device_list_add() should not update list when mounted Wang Shilong
2014-07-01 16:31 ` Anand Jain [this message]
2014-07-02 2:59 ` Wang Shilong
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=53B2E27D.2030609@oracle.com \
--to=anand.jain@oracle.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo@cn.fujitsu.com \
--cc=wangsl.fnst@cn.fujitsu.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.