From: Anand Jain <anandsuveer@gmail.com>
To: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>,
Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: dsterba@suse.cz, Nathan Dehnel <ncdehnel@gmail.com>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: How to replace a missing device with a smaller one
Date: Thu, 21 Nov 2019 18:21:14 +0800 [thread overview]
Message-ID: <fba31f91-a5d4-a443-0f03-56be73763d67@oracle.com> (raw)
In-Reply-To: <20191120000524.GE22121@hungrycats.org>
On 11/20/19 8:05 AM, Zygo Blaxell wrote:
> On Wed, Nov 20, 2019 at 08:02:43AM +0800, Qu Wenruo wrote:
>>
>>
>> On 2019/11/19 下午10:38, David Sterba wrote:
>>> On Mon, Nov 18, 2019 at 03:08:00PM +0800, Qu Wenruo wrote:
>>>> On 2019/11/18 下午1:32, Qu Wenruo wrote:
>>>>> On 2019/11/18 上午10:09, Nathan Dehnel wrote:
>>>>>> I have a 10-disk raid10 with a missing device I'm trying to replace. I
>>>>>> get this error when doing it though:
>>>>>>
>>>>>> btrfs replace start 1 /dev/bcache0 /mnt
>>>>>> ERROR: target device smaller than source device (required 1000203091968 bytes)
>>>>>>
>>>>>> I see that people recommend resizing a disk before replacing it, which
>>>>>> isn't an option for me because it's gone.
>>>>>
>>>>> Oh, that's indeed a problem.
>>>>>
>>>>> We should allow to change missing device's size.
>>>>
>>>> I have CCed you with a patch to allow user to *shrink* the missing device.
>>>>
>>>> You can also get the patch from patchwork:
>>>> https://patchwork.kernel.org/patch/11249009/
>>>>
>>>> Please give a try, since the device size is pretty small, I believe with
>>>> that patch, we can go quick shrink, that means "btrfs fi resize" command
>>>> should return immediately.
>>>
>>> So it can be recteated eg. on loop devices, where some of them are
>>> slightly smaller, then go missing and replace is started, right?
>>>
>>
>> Replace will still be rejected, but we can do resize of that missing
>> dev, then replace, as a workaround.
>>
>> I haven't do the auto-resize for replace yet, since I'm not sure if that
>> could make cases like replacing 1T device with 10G driver happening.
>
> That case would be much more tolerable if device replace/resize/delete would
> stop to check for fatal signals at least between block groups, if not more
> often. Currently if you pick the wrong size, the only way to make it stop
> is to reboot.
I agree. IMO too
btrfs replace --<option to skip-check|auto-resize>
is better as commented in the patch thread.
Already if you comment out the size checks[1], the replace with
a smaller device works fine. But But you have to manually estimate
the disk size for the actual consumption. So the effort here should
be auto pre-check.
[1]
diff --git a/cmds/replace.c b/cmds/replace.c
index 2321aa156fe2..1a4155d360d6 100644
--- a/cmds/replace.c
+++ b/cmds/replace.c
@@ -246,11 +246,13 @@ static int cmd_replace_start(const struct
cmd_struct *cmd,
goto leave_with_error;
dstdev_size = get_partition_size(dstdev);
+/*
if (srcdev_size > dstdev_size) {
error("target device smaller than source device
(required %llu bytes)",
srcdev_size);
goto leave_with_error;
}
+*/
fddstdev = open(dstdev, O_RDWR);
if (fddstdev < 0) {
diff --git a/fs/btrfs/dev-replace.c b/fs/btrfs/dev-replace.c
index 9a29d6de9017..86fc0f8653be 100644
--- a/fs/btrfs/dev-replace.c
+++ b/fs/btrfs/dev-replace.c
@@ -214,7 +214,7 @@ static int btrfs_init_dev_replace_tgtdev(struct
btrfs_fs_info *fs_info,
}
}
-
+/*
if (i_size_read(bdev->bd_inode) <
btrfs_device_get_total_bytes(srcdev)) {
btrfs_err(fs_info,
@@ -222,7 +222,7 @@ static int btrfs_init_dev_replace_tgtdev(struct
btrfs_fs_info *fs_info,
ret = -EINVAL;
goto error;
}
-
+*/
device = btrfs_alloc_device(NULL, &devid, NULL);
if (IS_ERR(device)) {
>> Thanks,
>> Qu
>>
>
>
>
next prev parent reply other threads:[~2019-11-21 10:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-18 2:09 How to replace a missing device with a smaller one Nathan Dehnel
2019-11-18 5:32 ` Qu Wenruo
2019-11-18 7:08 ` Qu Wenruo
2019-11-19 14:38 ` David Sterba
2019-11-20 0:02 ` Qu Wenruo
2019-11-20 0:05 ` Zygo Blaxell
2019-11-21 10:21 ` Anand Jain [this message]
2019-11-24 23:02 ` Nathan Dehnel
2019-11-20 17:07 ` Chris Murphy
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=fba31f91-a5d4-a443-0f03-56be73763d67@oracle.com \
--to=anandsuveer@gmail.com \
--cc=ce3g8jdj@umail.furryterror.org \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=ncdehnel@gmail.com \
--cc=quwenruo.btrfs@gmx.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 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).