Resize command syntax wrong?
Currently the resize command is under filesystem, and takes a path to the mounted filesystem. This seems wrong to me. Shouldn't it be under device, and take a path to a device to resize? Otherwise, how can a resize operation when you have multiple devices make any sense?
Hallo, Phillip,
Du meintest am 30.11.11:
Quoted 3 lines
Currently the resize command is under filesystem, and takes a path to the mounted filesystem. This seems wrong to me. Shouldn't it be under device, and take a path to a device to resize?
No - it's a filesystem operation.
p.e.
You start with a system of 2 disks. They get filled nearly simultaneously.
Then you add a 3rd disk (which is empty at that time). Now it's a good idea to run "balance" for equalizing the filling.
Viele Gruesse!
Helmut
Quoted 5 lines · On 30 Nov 2011 19:59:00 +0100 "Helmut Hullen" <[email protected]> wrote:
Quoted 3 lines
Currently the resize command is under filesystem, and takes a path to the mounted filesystem. This seems wrong to me. Shouldn't it be under device, and take a path to a device to resize?
No - it's a filesystem operation.
Are you sure about that?
Quoted 6 lines
p.e.
You start with a system of 2 disks. They get filled nearly simultaneously.
Then you add a 3rd disk (which is empty at that time). Now it's a good idea to run "balance" for equalizing the filling.
What if I need to replace an individual device with a smaller or a larger one?
Signature · 8 lines
With respect, Roman ~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Stallman had a printer, with code he could not see. So he began to tinker, and set the software free."
Quoted 11 lines · On Thursday, 01 December, 2011 01:15:47 you wrote:
On 30 Nov 2011 19:59:00 +0100
Quoted 6 lines · Helmut Hullen
Quoted 4 lines
Currently the resize command is under filesystem, and takes a path to
the mounted filesystem. This seems wrong to me. Shouldn't it be under device, and take a path to a device to resize?No - it's a filesystem operation.
Are you sure about that?
I confirm that. In fact "btrfs filesystem resize" doesn't change the device(s). It only expands or shrinks the filesystem.
Of course if you want to expand the filesystem, you have to expand the underling device *before*. Otherwise if you want to shrink the filesystem, you have to not shrink the device before shrinking the filesystem.
Quoted 9 lines
Quoted 6 lines
p.e.
You start with a system of 2 disks. They get filled nearly simultaneously.
Then you add a 3rd disk (which is empty at that time). Now it's a good idea to run "balance" for equalizing the filling.What if I need to replace an individual device with a smaller or a larger one?
This is a more simpler case
As general rule:
# btrfs device add <new device> <btrfs root> # btrfs device delete <old device> <btrfs root>
May be that the device removing is blocked in some RAID setup.
Signature · 2 lines
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <[email protected]> Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512
Hallo, Roman,
Du meintest am 01.12.11:
Quoted 2 lines
What if I need to replace an individual device with a smaller or a larger one?
1) add the new device
2) balance (may be it's not necessary)
3) run "remove" for the "individual" device
4) remove it
5) balance
Viele Gruesse!
Helmut
Quoted 4 lines · On 30 Nov 2011 20:43:00 +0100 "Helmut Hullen" <[email protected]> wrote:
Hallo, Roman,
Du meintest am 01.12.11:
Quoted 8 lines
Quoted 2 lines
What if I need to replace an individual device with a smaller or a larger one?
1) add the new device
2) balance (may be it's not necessary)
3) run "remove" for the "individual" device
4) remove it
5) balance
Okay, adding a new device wasn't the best example to explain my point.
What I meant is resizing a BTRFS partition, enlarging it or shrinking it as needed, while still on the same device.
Of course in the enlarge scenario the partition(or the LV) is resized upwards first, and then the filesystem, and on shrinking it's vice versa. Suppose I used half of a 1000GB disk for BTRFS (a 500GB partition), and the second half for something else. Now I want to remove this other partition, and make BTRFS occupy the whole disk.
Resizing in both 'directions' seems to work very well on single-device BTRFS filesystems, and also it's very useful that BTRFS is almost the only modern FS (besides ext4) that can be shrinked. But with multi-device filesystems, don't you agree it's non-obvious how (or is not even possible) to resize the areas that BTRFS occupies on individual devices?
Signature · 8 lines
With respect, Roman ~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Stallman had a printer, with code he could not see. So he began to tinker, and set the software free."
On Thursday, 01 December, 2011 02:07:30 you wrote:
[...]
Quoted 5 lines
Resizing in both 'directions' seems to work very well on single-device BTRFS filesystems, and also it's very useful that BTRFS is almost the only modern FS (besides ext4) that can be shrinked. But with multi-device filesystems, don't you agree it's non-obvious how (or is not even possible) to resize the areas that BTRFS occupies on individual devices?
I agree that it is not so an obviously syntax, however it is definitely possible to shrink/grow a single disk in a multi disk scenario.
The full syntax is the following ([1])
-----------
filesystem resize [<devid>:][+/-]<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 be suffixed by one of the following the units designators: '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.
<devid> is the id of the device which was grow or shrink, as show by the command btrfs filesystem show. If nothing is passed, the device devid=1 is used.
----------------------
IIRC I sent in the past a patch which added these further info in the man page, but I think that this patch was lost... I have to resubmit another time
BR
G.Baroncelli
[1] http://btrfs.ipv5.de/index.php?title=Btrfs(command)
Signature · 2 lines
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <[email protected]> Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512
Hallo, Roman,
Du meintest am 01.12.11:
Quoted 5 lines
Okay, adding a new device wasn't the best example to explain my point.
What I meant is resizing a BTRFS partition, enlarging it or shrinking it as needed, while still on the same device.
That's no good example, too.
btrfs allows to bundle several disks. Your example is a very special case.
Viele Gruesse!
Helmut
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 9 lines · Helmut Hullen
Hallo, Phillip,
Du meintest am 30.11.11:
Quoted 3 lines
Currently the resize command is under filesystem, and takes a path to the mounted filesystem. This seems wrong to me. Shouldn't it be under device, and take a path to a device to resize?
No - it's a filesystem operation.
No, it isn't. You can see the function that implements the resize in the code operates on a specific disk, and the ioctl does take as an argument which disk you are trying to resize. Logically you are adjusting the space that is available on a particular device, which only indirectly affects the filesystem. In other words, the only reason that the size of the filesystem changes is because you have changed the size of a device. In fact, internally device removal is implemented by first resizing the device to 0.
It appears that the utility just passes devid=1 to the kernel when you don't specify it. It should take a dev node as an argument and translate it to the devid for you.
Quoted 5 lines
p.e.
You start with a system of 2 disks. They get filled nearly simultaneously.
Then you add a 3rd disk (which is empty at that time). Now it's a good idea to run "balance" for equalizing the filling.
balance != resize
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7Ww+gACgkQJ4UciIs+XuJjlwCgr2u3zvuhYWC0vv9ObdhBS41Z M3MAn09xhEopzuIJdN4QP+8bQvYzhvo1
=Qck2
-----END PGP SIGNATURE-----
Hallo, Phillip,
Du meintest am 30.11.11:
Quoted 6 lines
Quoted 4 lines
You start with a system of 2 disks. They get filled nearly simultaneously.
Then you add a 3rd disk (which is empty at that time). Now it's a good idea to run "balance" for equalizing the filling.balance != resize
I know.
p.e.
Start with 1 disk with 2 GB and 1 disk with 4 GByte Fill it with 2 Gbyte data, each disk gets 1 GByte.
Add a disk with 10 GByte, run "balance": each disk gets about 700 MByte.
That has nothing to do with "resize".
Viele Gruesse!
Helmut
Quoted 11 lines · Helmut Hullen
Quoted 1 line
balance != resize
I know.
p.e.
Start with 1 disk with 2 GB and 1 disk with 4 GByte Fill it with 2 Gbyte data, each disk gets 1 GByte.Add a disk with 10 GByte, run "balance": each disk gets about 700 MByte.
That has nothing to do with "resize".
Right, so why are you talking about balance when this thread is about resize?
Hallo, Phillip,
Du meintest am 01.12.11:
Quoted 1 line
Quoted 1 line
Quoted 1 line
balance != resize
[...]
Quoted 4 lines
Quoted 1 line
That has nothing to do with "resize".
Right, so why are you talking about balance when this thread is about resize?
Ooops - sorry!
Viele Gruesse!
Helmut