linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
>>
> 
> 
> 


  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).