Discussion:
How to expand a BTRFS partition... backwards
Sebastian 'gonX' Jensen
2010-05-02 05:32:34 UTC
Permalink
Hey guys,

I kinda figured out the syntax for resizing BTRFS arrays, but is it
possible to use free space that is behind the current BTRFS partition?
I kinda figure it's not, but ideally I'd like it so that there is no
unused disk space on the disk.

My partition setup looks something like this:

Partition 1: 100MB (used)
Partition 2: 256MB (not used, this is what I want to use)
Partition 3: 200GB (used, for BTRFS)
Partition 4: 50GB (not used, but this will be expanded to the current
BTRFS partition)

Also as a last note (just in case I've misunderstood something), to
resize properly, you should first delete the partition using a
partition editor like fdisk, then recreate a new partition with the
same start cylinders as the original setup, but with bigger/later end
cylinders than the original setup, right? Then e.g. btrfsctl -r +45G /
What if I have a RAID-0 array (which I do), which uses the RAID-0
routine by BTRFS (and not mdraid or dmraid). Should I then do a
"btrfsctl -R +(size*disks)G /" or btrfsctl -R +(size of all disks)G
/"?

Regards,
Sebastian J.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Sebastian 'gonX' Jensen
2010-05-02 06:23:04 UTC
Permalink
Thanks, I figured that the new btrfs tool would have something easier.
Now I only need to know whether expanding btrfs is also possible
backwards on the harddrive.

Regards,
Sebastian J.
=C2=A0 =C2=A0 =C2=A0 filesystem resize [+/-]<size>[gkm]|max <path>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Resize =C2=A0a filesy=
stem identified by <path>. =C2=A0The <size>
parameter
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0specifies the new siz=
e of the filesystem. =C2=A0If the prefix +
or =C2=A0-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is =C2=A0present =C2=A0=
the =C2=A0size is increased or decreased by the
quantity
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<size>. =C2=A0If no u=
nits are =C2=A0specified, =C2=A0the =C2=A0unit =C2=A0of =C2=A0the
<size>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0parameter =C2=A0defau=
lts to bytes. Optionally, the size
parameter may
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be suffixed by one of=
=C2=A0'K',
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'M', or 'G', kilobyte=
s, megabytes, or gigabytes, respectively.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If =C2=A0'max' =C2=A0=
is =C2=A0passed, =C2=A0the filesystem will occupy all
available
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0space on the volume(s=
).
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The resize command do=
es not manipulate the =C2=A0size =C2=A0of
underlying
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0partition. =C2=A0If y=
ou wish to enlarge/reduce a filesystem,
you must
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0make sure you can exp=
and =C2=A0the =C2=A0partition =C2=A0before
enlarging =C2=A0the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0filesystem =C2=A0and =
=C2=A0shrink the partition after reducing the
size of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the filesystem.
(this is for the new btrfs - btrfsctl shoud do something similar).
So, as I read it, simply expand (recreate) the partitions (as you say=
ed)
btrfs resize max /dev/sdxY (or something similay in brtfsctl).
But I can't give you a guarantee as I simply interpreted the manpage
right now and never tried this.
P.s. sorry for my bad english :)
Post by Sebastian 'gonX' Jensen
Hey guys,
I kinda figured out the syntax for resizing BTRFS arrays, but is it
possible to use free space that is behind the current BTRFS partitio=
n?
Post by Sebastian 'gonX' Jensen
I kinda figure it's not, but ideally I'd like it so that there is no
unused disk space on the disk.
Partition 1: 100MB (used)
Partition 2: 256MB (not used, this is what I want to use)
Partition 3: 200GB (used, for BTRFS)
Partition 4: 50GB (not used, but this will be expanded to the curren=
t
Post by Sebastian 'gonX' Jensen
BTRFS partition)
Also as a last note (just in case I've misunderstood something), to
resize properly, you should first delete the partition using a
partition editor like fdisk, then recreate a new partition with the
same start cylinders as the original setup, but with bigger/later en=
d
Post by Sebastian 'gonX' Jensen
cylinders than the original setup, right? Then e.g. btrfsctl -r +45G=
/
Post by Sebastian 'gonX' Jensen
What if I have a RAID-0 array (which I do), which uses the RAID-0
routine by BTRFS (and not mdraid or dmraid). Should I then do a
"btrfsctl -R +(size*disks)G /" or btrfsctl -R +(size of all disks)G
/"?
Regards,
Sebastian J.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrf=
s" in
Post by Sebastian 'gonX' Jensen
More majordomo info at =C2=A0http://vger.kernel.org/majordomo-info.h=
tml
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
TAXI
2010-05-02 08:10:12 UTC
Permalink
I played a bit with my btrfs partition and btrfs filesystem resize
didn't work.
But I found a commando that worked:
btrfsctl -r max /mnt/btrfs
(yes, on the mounted FS -
http://kerneltrap.org/Linux/Btrfs_Online_Resizing_Ext3_Conversion_and_More )

But I don't know if expanding is possible backwards. I have no free
drive to test.
Post by Sebastian 'gonX' Jensen
Thanks, I figured that the new btrfs tool would have something easier.
Now I only need to know whether expanding btrfs is also possible
backwards on the harddrive.
Regards,
Sebastian J.
filesystem resize [+/-]<size>[gkm]|max <path>
Resize a filesystem identified by <path>. The <size>
parameter
specifies the new size of the filesystem. If the prefix +
or -
is present the size is increased or decreased by the
quantity
<size>. If no units are specified, the unit of the
<size>
parameter defaults to bytes. Optionally, the size
parameter may
'K',
'M', or 'G', kilobytes, megabytes, or gigabytes, respectively.
If 'max' is passed, the filesystem will occupy all
available
space on the volume(s).
The resize command does not manipulate the size of
underlying
partition. If you wish to enlarge/reduce a filesystem,
you must
make sure you can expand the partition before
enlarging the
filesystem and shrink the partition after reducing the
size of
the filesystem.
(this is for the new btrfs - btrfsctl shoud do something similar).
So, as I read it, simply expand (recreate) the partitions (as you sayed)
btrfs resize max /dev/sdxY (or something similay in brtfsctl).
But I can't give you a guarantee as I simply interpreted the manpage
right now and never tried this.
P.s. sorry for my bad english :)
Post by Sebastian 'gonX' Jensen
Hey guys,
I kinda figured out the syntax for resizing BTRFS arrays, but is it
possible to use free space that is behind the current BTRFS partition?
I kinda figure it's not, but ideally I'd like it so that there is no
unused disk space on the disk.
Partition 1: 100MB (used)
Partition 2: 256MB (not used, this is what I want to use)
Partition 3: 200GB (used, for BTRFS)
Partition 4: 50GB (not used, but this will be expanded to the current
BTRFS partition)
Also as a last note (just in case I've misunderstood something), to
resize properly, you should first delete the partition using a
partition editor like fdisk, then recreate a new partition with the
same start cylinders as the original setup, but with bigger/later end
cylinders than the original setup, right? Then e.g. btrfsctl -r +45G /
What if I have a RAID-0 array (which I do), which uses the RAID-0
routine by BTRFS (and not mdraid or dmraid). Should I then do a
"btrfsctl -R +(size*disks)G /" or btrfsctl -R +(size of all disks)G
/"?
Regards,
Sebastian J.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Sebastian 'gonX' Jensen
2010-05-03 03:15:22 UTC
Permalink
Post by Sebastian 'gonX' Jensen
Hey guys,
I kinda figured out the syntax for resizing BTRFS arrays, but is it
possible to use free space that is behind the current BTRFS partitio=
n?
Post by Sebastian 'gonX' Jensen
I kinda figure it's not, but ideally I'd like it so that there is no
unused disk space on the disk.
Partition 1: 100MB (used)
Partition 2: 256MB (not used, this is what I want to use)
Partition 3: 200GB (used, for BTRFS)
Partition 4: 50GB (not used, but this will be expanded to the curren=
t
Post by Sebastian 'gonX' Jensen
BTRFS partition)
Also as a last note (just in case I've misunderstood something), to
resize properly, you should first delete the partition using a
partition editor like fdisk, then recreate a new partition with the
same start cylinders as the original setup, but with bigger/later en=
d
Post by Sebastian 'gonX' Jensen
cylinders than the original setup, right? Then e.g. btrfsctl -r +45G=
/
Post by Sebastian 'gonX' Jensen
What if I have a RAID-0 array (which I do), which uses the RAID-0
routine by BTRFS (and not mdraid or dmraid). Should I then do a
"btrfsctl -R +(size*disks)G /" or btrfsctl -R +(size of all disks)G
/"?
Regards,
Sebastian J.
File systems grow (and shrink) at the end, not by moving the
beginning. =C2=A0However, you can achieve what you are after in this =
case
as the source partition 3 is smaller that the partition 2 before it.
Simply copy the BTRFS from partition 3 to partition 2 and then grow
partition 2 as required.
1) Unmount BTRFS.
# umount /mntpoint
2) Copy BTRFS.
# dd if=3D/dev/sda3 of=3D/dev/sda2 bs=3D1M
3) Re-partition disk.
# fdisk /dev/sda
Record start of partition 2 and size of partition =C2=A03.
Delete partitions 2, 3 and 4.
Re-create partition 2 from previous start and of size >=3D old partit=
ion 3 size.
4) Mount the BTRFS.
# mount /dev/sda2 /mntpoint
5) Grow the BTRFS to fill the larger partition 2.
# btrfs filesystem resize max /mntpoint
6) Update /etc/fstab if needed.
(If refer to file systems by device like /dev/sda3 rather than UUID=3D=
or LABEL=3D).
1.1) Boot from a live or rescue CD or USB key.
1.2) Update boot loader for new root (/) file system location if
needed. (If using /dev rather than UUID=3D or LABEL=3D).
2) Fdisk (and every other tool) will report that the kernel was unabl=
e
to re-read the updated partition table if any partitions are mounted
from it. =C2=A0Unmount all partitions and run 'partprobe' (or other
command) or reboot.
Mike
=46irstly, I'm resending this. I forgot to add linux-btrfs to the recip=
ients list.

Secondly, thanks Mike! I figured I'd have to go through a lot of hoops
to make that work.
Suffice to say, that isn't really possible in my case, considering I
only have a small 256MB partition in front of the 200GB partition.

A have a different question now - can you really have differently
sized partitions spread out on a RAID-0 array? e.g. 2x 200GB and 3x
250GB? That's what I was trying to do, but the drives are getting
remove now.

I'm having an issue with increasing the size though, it seems only to
be doing this on the first drive of the array.

***@m ~ # btrfsctl -r max /
ioctl:: Invalid argument
***@m ~ # btrfs-show
Label: none uuid: 405f0d0b-ee4d-4426-9826-d2580d0c8d6c
Total devices 4 FS bytes used 443.41GB
devid 3 size 189.59GB used 163.00GB path /dev/sda3
devid 4 size 189.59GB used 163.00GB path /dev/sdc3
devid 5 size 189.59GB used 92.00GB path /dev/sdd3
devid 1 size 232.55GB used 181.01GB path /dev/sde3
Btrfs Btrfs v0.19

BTW the reason why /dev/sdd3 has less used than the other drives is
because I'm planning to remove it from the array, but it crashed while
doing it last time - I assume it's because there isn't enough space.
This isn't important though, I just want to get sda3 and sdc3 to get
their sizes increased in btrfs.

As you can see, my drives are already repartitioned, and they still
seem to mount fine:
***@m ~ # fdisk -l /dev/sd{a..e}
Disk /dev/sda: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
/dev/sda1 * 1 12 96358+ fd Linux raid auto=
detect
/dev/sda2 13 43 249007+ 83 Linux
/dev/sda3 44 30401 243850635 83 Linux

Disk /dev/sdc: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
/dev/sdc1 * 1 12 96358+ fd Linux raid auto=
detect
/dev/sdc2 13 43 249007+ 83 Linux
/dev/sdc3 44 30401 243850635 83 Linux

Disk /dev/sdd: 203.9 GB, 203927027200 bytes
255 heads, 63 sectors/track, 24792 cylinders
/dev/sdd1 * 1 12 96358+ fd Linux raid auto=
detect
/dev/sdd3 44 24792 198796342+ 83 Linux

Disk /dev/sde: 250.1 GB, 250058268160 bytes
255 heads, 63 sectors/track, 30401 cylinders
/dev/sde1 * 1 12 96358+ fd Linux raid auto=
detect
/dev/sde2 13 43 249007+ 83 Linux
/dev/sde3 44 30401 243850635 83 Linux

Any help on this one, or a possible bug report?

Regards,
Sebastian J.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Loading...