linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: "Christian Völker" <cvoelker@knebb.de>,
	"Hugo Mills" <hugo@carfax.org.uk>,
	linux-btrfs@vger.kernel.org
Subject: Re: Resizing BTRFS - raw partition
Date: Wed, 2 Nov 2016 07:40:31 -0400	[thread overview]
Message-ID: <4748119f-099c-9403-511a-4888cf1f5c3e@gmail.com> (raw)
In-Reply-To: <6050c1f3-ff13-204c-ec32-3bcb62db7c5a@knebb.de>

On 2016-11-02 05:18, Christian Völker wrote:
> Hi Hugo,
>
> thanks for the quick reply. Regarding version- I prefer to use stable
> Linux versions....and I am not going to upgrade just btrfs outside of
> the verndors builds. So I am stuck happily with this version. And I run
> Linux since more than 10years, so I am really fine with it, I guess :D
>
> And thanks again for your proposal. Yes, your command worked.
>
> I had to tell betrfs the devid!
>
> So this did NOT work:
>
>  btrfs fi resize  max /srv/share/
>
> Instead the following two commands worked:
>
>  btrfs fi resize  1:max /srv/share/
>  btrfs fi resize  2:max /srv/share/
>
> And now boths phydevices show the correct size.
>
> This sound really strange for me that I have to tell btrfs to resize
> just a single disk insteag of automatically resizing all disks...I bet
> next time I have it forgotten again :-(
Responding just to this in particular.

The reasoning behind this is that by requiring the device ID to be 
specified, it reduces the amount of parsing required, which in turn 
makes the command more robust.  There are also plenty of practical 
reasons to resize just one device in a multi-device filesystem (for 
example, if you're replacing one disk at a time, or just need to free up 
some space on a single disk, etc), so we need to have support for that, 
and in turn it's easier from a software maintenance perspective to just 
require it to be that way.

That said, I would love to have 'btrfs fi resize max' special cased to 
just resize every device in the FS to max size, since increasing the 
size of a device is much more common than reducing it, and it's a lot 
more convenient than having to look up device ID's (because those can 
change as devices are added to and removed from the FS).


      parent reply	other threads:[~2016-11-02 11:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-02  8:58 Resizing BTRFS - raw partition Christian Völker
2016-11-02  9:12 ` Hugo Mills
2016-11-02  9:18   ` Christian Völker
2016-11-02  9:29     ` Hugo Mills
2016-11-02 10:14       ` Adam Borowski
2016-11-02 10:16         ` Christian Völker
2016-11-02 11:40     ` Austin S. Hemmelgarn [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=4748119f-099c-9403-511a-4888cf1f5c3e@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=cvoelker@knebb.de \
    --cc=hugo@carfax.org.uk \
    --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).