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