Resizing BTRFS - raw partition

Resizing BTRFS - raw partition

[Christian Völker]

Hi all,

I am using btrfs as follows:
root@srv:/srv# btrfs filesystem show
Label: none  uuid: c8f24351-ddc4-4866-843c-4e95fcb498d4
        Total devices 2 FS bytes used 1005.37GB
        devid    2 size 1.00TB used 1023.98GB path /dev/sdc
        devid    1 size 1.46TB used 1.00TB path /dev/sdb

Btrfs Btrfs v0.19

It is running inside a virtual machines running on VMware ESXi. I
increased both virtual disks to 1.5TB now. I did a scsi-rescan and fdisk
-l tells me the new size:
Disk /dev/sdb: 1610.6 GB, 1610612736000 bytes
Disk /dev/sdc: 1610.6 GB, 1610612736000 bytes

There are no partitions created on the disks, just raw devices used for
BTRFS. I found several sites where they resized a btrfs filesystem based
on LVM and the new size was immediately recognized. But how to do on raw
partitions?

How do I tell btrfs the devices have been resized?
I did not find a rescan command. btrfs scan does not change anything. 
Do I really have to reboot?

Thanks!

Christian

Re: Resizing BTRFS - raw partition

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1710 bytes --]

On Wed, Nov 02, 2016 at 09:58:41AM +0100, Christian Völker wrote:
> Hi all,
> 
> I am using btrfs as follows:
> root@srv:/srv# btrfs filesystem show
> Label: none  uuid: c8f24351-ddc4-4866-843c-4e95fcb498d4
>         Total devices 2 FS bytes used 1005.37GB
>         devid    2 size 1.00TB used 1023.98GB path /dev/sdc
>         devid    1 size 1.46TB used 1.00TB path /dev/sdb
> 
> Btrfs Btrfs v0.19

   That's positively antique. If your kernel is anything close to the
same age, this experience with btrfs is probably going to be extremely
painful for you.

> It is running inside a virtual machines running on VMware ESXi. I
> increased both virtual disks to 1.5TB now. I did a scsi-rescan and fdisk
> -l tells me the new size:
> Disk /dev/sdb: 1610.6 GB, 1610612736000 bytes
> Disk /dev/sdc: 1610.6 GB, 1610612736000 bytes
> 
> There are no partitions created on the disks, just raw devices used for
> BTRFS. I found several sites where they resized a btrfs filesystem based
> on LVM and the new size was immediately recognized. But how to do on raw
> partitions?

   Than those sites are mistaken. :)

> How do I tell btrfs the devices have been resized?
> I did not find a rescan command. btrfs scan does not change anything. 
> Do I really have to reboot?

   btrfs fi resize <devid>:max /mountpoint

   btrfs dev scan is just used to tell the kernel which devices
contain [parts of] which btrfs filesystems.

   Hugo.

-- 
Hugo Mills             | In one respect at least, the Martians are a happy
hugo@... carfax.org.uk | people: they have no lawyers
http://carfax.org.uk/  |
PGP: E2AB1DE4          |                       John Carter, A Princess of Mars

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Resizing BTRFS - raw partition

[Christian Völker]

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 :-(


Greetings


Christian

Re: Resizing BTRFS - raw partition

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 2051 bytes --]

On Wed, Nov 02, 2016 at 10:18:03AM +0100, 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

   Well, btrfs-progs 0.19 was last released several years ago. If your
kernel is of the same kind of age, then you're going to be seeing a
whole load of really nasty data-corrupting or filesystem-breaking bugs
which have since been fixed. Basically, if something goes wrong with
your FS when you're running a kernel that old, the main rsponse you'll
get is, "well, that was silly of you, wasn't it?", and you'll have to
make a new filesystem and restore from your backups and hope it
doesn't happen again.

   I would currently recommend running a 4.4 kernel or later. If you
want a "stable" kernel version from a distribution, and want some kind
of support for it when it goes wrong, you're probably going to have to
pay someone (Red Hat or SuSE, most likely) to support your
configuraion.

   Hugo.

> 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 :-(
> 
> 
> Greetings
> 
> 
> Christian
> 
> 
> 

-- 
Hugo Mills             | In one respect at least, the Martians are a happy
hugo@... carfax.org.uk | people: they have no lawyers
http://carfax.org.uk/  |
PGP: E2AB1DE4          |                       John Carter, A Princess of Mars

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Resizing BTRFS - raw partition

[Adam Borowski]

On Wed, Nov 02, 2016 at 09:29:26AM +0000, Hugo Mills wrote:
> On Wed, Nov 02, 2016 at 10:18:03AM +0100, Christian Völker wrote:
> > 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
> 
>    Well, btrfs-progs 0.19 was last released several years ago. If your
> kernel is of the same kind of age, then you're going to be seeing a
> whole load of really nasty data-corrupting or filesystem-breaking bugs
> which have since been fixed. Basically, if something goes wrong with
> your FS when you're running a kernel that old, the main rsponse you'll
> get is, "well, that was silly of you, wasn't it?", and you'll have to
> make a new filesystem and restore from your backups and hope it
> doesn't happen again.

-progs 0.19 imply kernel 2.6.32 which comes from btrfs' infancy, when it
was hardly merged into mainline.  It's buggier than experimental features
like RAID5/6 nowadays.

>    I would currently recommend running a 4.4 kernel or later. If you
> want a "stable" kernel version from a distribution, and want some kind
> of support for it when it goes wrong, you're probably going to have to
> pay someone (Red Hat or SuSE, most likely) to support your
> configuraion.

Kernels around 3.16 or so are pretty reliable -- ones I'm using on
production are 3.13 and 3.14, without a single issue.

As 2.6.32 is for you "stable" rather than "ancient and unsupported", I guess
you're on RHEL or a derivative.  For them, 3.10 is the next stable, which
is on the verge of what could be reasonable (but I still second Hugo's
advice of using at least the current LTS kernel, ie 4.4).

TL;DR:
DO NOT USE BTRFS ON ANCIENT KERNELS!!1!elebenty-one!


Meow!
-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.

Re: Resizing BTRFS - raw partition

[Christian Völker]

Yohoo!

Well, slightly off-topic now.

It is a Debian derivative. Univention Corporate Server.

uname -r says: 4.1.0-ucs190-amd64

So I am pretty fine with the kernel.

But indeed, I have to think about getting a more up-to-date btrfs as I
ran on resizing in the "File too large" issue so I had to use "max"
instead of "+100G". No big deal, just a minor issue.

I use btrfs to checksum all files stored there as I had several issues
the last years where files got corrupted.

Greetings

Christian


Am 02.11.2016 um 11:14 schrieb Adam Borowski:
> On Wed, Nov 02, 2016 at 09:29:26AM +0000, Hugo Mills wrote:
>> On Wed, Nov 02, 2016 at 10:18:03AM +0100, Christian Völker wrote:
>>> 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
>>    Well, btrfs-progs 0.19 was last released several years ago. If your
>> kernel is of the same kind of age, then you're going to be seeing a
>> whole load of really nasty data-corrupting or filesystem-breaking bugs
>> which have since been fixed. Basically, if something goes wrong with
>> your FS when you're running a kernel that old, the main rsponse you'll
>> get is, "well, that was silly of you, wasn't it?", and you'll have to
>> make a new filesystem and restore from your backups and hope it
>> doesn't happen again.
> -progs 0.19 imply kernel 2.6.32 which comes from btrfs' infancy, when it
> was hardly merged into mainline.  It's buggier than experimental features
> like RAID5/6 nowadays.
>
>>    I would currently recommend running a 4.4 kernel or later. If you
>> want a "stable" kernel version from a distribution, and want some kind
>> of support for it when it goes wrong, you're probably going to have to
>> pay someone (Red Hat or SuSE, most likely) to support your
>> configuraion.
> Kernels around 3.16 or so are pretty reliable -- ones I'm using on
> production are 3.13 and 3.14, without a single issue.
>
> As 2.6.32 is for you "stable" rather than "ancient and unsupported", I guess
> you're on RHEL or a derivative.  For them, 3.10 is the next stable, which
> is on the verge of what could be reasonable (but I still second Hugo's
> advice of using at least the current LTS kernel, ie 4.4).
>
> TL;DR:
> DO NOT USE BTRFS ON ANCIENT KERNELS!!1!elebenty-one!
>
>
> Meow!

Re: Resizing BTRFS - raw partition

[Austin S. Hemmelgarn]

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