Resize doesnt work as expected

Resize doesnt work as expected

[Peter Becker]

Hello, i have found a small issue but i doesn't know if this is intended.

Starting with a RAID 1 setup with 3 x 4GB devices.
If you replace one of this devices with a 2GB device and run "resize
max" nothing happens.
Only if you resize with the device-ID the additional GB will be usable.
Loop at this demo:
(its my first try with  loopback devices :))


[ -f /tmp_resize ] && rm -f /tmp_resize

mkdir /tmp_resize
dd if=/dev/zero of=/tmp_resize/btrfs-vol1.img bs=1G count=1
dd if=/dev/zero of=/tmp_resize/btrfs-vol2.img bs=1G count=1
dd if=/dev/zero of=/tmp_resize/btrfs-vol3.img bs=1G count=1
dd if=/dev/zero of=/tmp_resize/btrfs-vol4.img bs=1G count=1
dd if=/dev/zero of=/tmp_resize/btrfs-vol5.img bs=2G count=1

losetup /dev/loop1 /tmp_resize/btrfs-vol1.img
losetup /dev/loop2 /tmp_resize/btrfs-vol2.img
losetup /dev/loop3 /tmp_resize/btrfs-vol3.img
losetup /dev/loop4 /tmp_resize/btrfs-vol4.img
losetup /dev/loop5 /tmp_resize/btrfs-vol5.img

mkfs.btrfs -d raid1 /dev/loop1 /dev/loop2 /dev/loop3 /dev/loop4

btrfs filesystem show /dev/loop2

mkdir /media/test

mount /dev/loop3 /media/test

echo "Vorher"
btrfs fi sh

echo "Replace 1G device with 2G device"
btrfs repl start /dev/loop4 /dev/loop5 /media/test

echo "After replace, still 1GB usable"
btrfs fi sh

echo "Resize"
btrfs fi res max /media/test

echo "After resize, still 1GB usable !!!!"
btrfs fi sh

echo "Resize with device id"
btrfs fi res 4:max /media/test

echo "!!! now 2GB usable !!!!"
btrfs fi sh

Re: Resize doesnt work as expected

[Alexander Fougner]

2016-05-28 22:32 GMT+02:00 Peter Becker <floyd.net@gmail.com>:
> Hello, i have found a small issue but i doesn't know if this is intended.
>
> Starting with a RAID 1 setup with 3 x 4GB devices.
> If you replace one of this devices with a 2GB device and run "resize
> max" nothing happens.

>From manpages:
"The devid can be found in the output of btrfs filesystem show and
defaults to 1 if not specified."

> Only if you resize with the device-ID the additional GB will be usable.
> Loop at this demo:
> (its my first try with  loopback devices :))
>
>
> [ -f /tmp_resize ] && rm -f /tmp_resize
>
> mkdir /tmp_resize
> dd if=/dev/zero of=/tmp_resize/btrfs-vol1.img bs=1G count=1
> dd if=/dev/zero of=/tmp_resize/btrfs-vol2.img bs=1G count=1
> dd if=/dev/zero of=/tmp_resize/btrfs-vol3.img bs=1G count=1
> dd if=/dev/zero of=/tmp_resize/btrfs-vol4.img bs=1G count=1
> dd if=/dev/zero of=/tmp_resize/btrfs-vol5.img bs=2G count=1
>
> losetup /dev/loop1 /tmp_resize/btrfs-vol1.img
> losetup /dev/loop2 /tmp_resize/btrfs-vol2.img
> losetup /dev/loop3 /tmp_resize/btrfs-vol3.img
> losetup /dev/loop4 /tmp_resize/btrfs-vol4.img
> losetup /dev/loop5 /tmp_resize/btrfs-vol5.img
>
> mkfs.btrfs -d raid1 /dev/loop1 /dev/loop2 /dev/loop3 /dev/loop4
>
> btrfs filesystem show /dev/loop2
>
> mkdir /media/test
>
> mount /dev/loop3 /media/test
>
> echo "Vorher"
> btrfs fi sh
>
> echo "Replace 1G device with 2G device"
> btrfs repl start /dev/loop4 /dev/loop5 /media/test
>
> echo "After replace, still 1GB usable"
> btrfs fi sh
>
> echo "Resize"
> btrfs fi res max /media/test

There is an invisible 1:max there which is why it doesnt resize the
newly replaced device.
>
> echo "After resize, still 1GB usable !!!!"
> btrfs fi sh
>
> echo "Resize with device id"
> btrfs fi res 4:max /media/test
>
> echo "!!! now 2GB usable !!!!"
> btrfs fi sh
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Resize doesnt work as expected

[Peter Becker]

Thanks for the clarification. I've probably overlooked this.

But should "resize max" does not do what you expect instead of falling
back on an "invisible" 1?


2016-05-28 22:52 GMT+02:00 Alexander Fougner <fougner89@gmail.com>:
> 2016-05-28 22:32 GMT+02:00 Peter Becker <floyd.net@gmail.com>:
>> Hello, i have found a small issue but i doesn't know if this is intended.
>>
>> Starting with a RAID 1 setup with 3 x 4GB devices.
>> If you replace one of this devices with a 2GB device and run "resize
>> max" nothing happens.
>
> From manpages:
> "The devid can be found in the output of btrfs filesystem show and
> defaults to 1 if not specified."
>
>> Only if you resize with the device-ID the additional GB will be usable.
>> Loop at this demo:
>> (its my first try with  loopback devices :))
>>
>>
>> [ -f /tmp_resize ] && rm -f /tmp_resize
>>
>> mkdir /tmp_resize
>> dd if=/dev/zero of=/tmp_resize/btrfs-vol1.img bs=1G count=1
>> dd if=/dev/zero of=/tmp_resize/btrfs-vol2.img bs=1G count=1
>> dd if=/dev/zero of=/tmp_resize/btrfs-vol3.img bs=1G count=1
>> dd if=/dev/zero of=/tmp_resize/btrfs-vol4.img bs=1G count=1
>> dd if=/dev/zero of=/tmp_resize/btrfs-vol5.img bs=2G count=1
>>
>> losetup /dev/loop1 /tmp_resize/btrfs-vol1.img
>> losetup /dev/loop2 /tmp_resize/btrfs-vol2.img
>> losetup /dev/loop3 /tmp_resize/btrfs-vol3.img
>> losetup /dev/loop4 /tmp_resize/btrfs-vol4.img
>> losetup /dev/loop5 /tmp_resize/btrfs-vol5.img
>>
>> mkfs.btrfs -d raid1 /dev/loop1 /dev/loop2 /dev/loop3 /dev/loop4
>>
>> btrfs filesystem show /dev/loop2
>>
>> mkdir /media/test
>>
>> mount /dev/loop3 /media/test
>>
>> echo "Vorher"
>> btrfs fi sh
>>
>> echo "Replace 1G device with 2G device"
>> btrfs repl start /dev/loop4 /dev/loop5 /media/test
>>
>> echo "After replace, still 1GB usable"
>> btrfs fi sh
>>
>> echo "Resize"
>> btrfs fi res max /media/test
>
> There is an invisible 1:max there which is why it doesnt resize the
> newly replaced device.
>>
>> echo "After resize, still 1GB usable !!!!"
>> btrfs fi sh
>>
>> echo "Resize with device id"
>> btrfs fi res 4:max /media/test
>>
>> echo "!!! now 2GB usable !!!!"
>> btrfs fi sh
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Resize doesnt work as expected

[Chris Murphy]

On Sat, May 28, 2016 at 3:42 PM, Peter Becker <floyd.net@gmail.com> wrote:
> Thanks for the clarification. I've probably overlooked this.
>
> But should "resize max" does not do what you expect instead of falling
> back on an "invisible" 1?

How does it know what the user expects?

I think the issue is not with the resize command, but rather the
replace command does not include the resize max operation. Presumably
the user intends the entire block device provided as the target for
replacement to be used.

So I think the mistake is replace assumes the user wants to use the
same amount of space as the former block device. I think if the user
wanted to use the former block device size on the new block device,
they'd partition it and use the partition as the target.


-- 
Chris Murphy

Re: Resize doesnt work as expected

[Peter Becker]

2016-05-29 19:11 GMT+02:00 Chris Murphy <lists@colorremedies.com>:
> On Sat, May 28, 2016 at 3:42 PM, Peter Becker <floyd.net@gmail.com> wrote:
>> Thanks for the clarification. I've probably overlooked this.
>>
>> But should "resize max" does not do what you expect instead of falling
>> back on an "invisible" 1?
>
> How does it know what the user expects?

Then simply remove the default deviceid und let the user choise what the want.
IMHO its a bad think to choise automaticly a option if its not clear
what the user wants. And in spezial there is no hint in the output of
the deviceid who is used.
The output is:

"Resize '/mnt' of 'max'" .. no hint the this only affect the deviceid
1. The suggestion for me is that the whole pool is resized to max.

Possible solutions:
1. remove the default deviceid
2. resize without deviceid affects the whole pool
3. improve the output of the resize command by adding the deviceid
4. remove the inconsitent between add+remove and replace by triggering
resize max after replace is finished.

> I think the issue is not with the resize command, but rather the
> replace command does not include the resize max operation. Presumably
> the user intends the entire block device provided as the target for
> replacement to be used.
>
> So I think the mistake is replace assumes the user wants to use the
> same amount of space as the former block device. I think if the user
> wanted to use the former block device size on the new block device,
> they'd partition it and use the partition as the target.
>
>
> --
> Chris Murphy

Re: Resize doesnt work as expected

[Chris Murphy]

On Sun, May 29, 2016 at 12:16 PM, Peter Becker <floyd.net@gmail.com> wrote:
> 2016-05-29 19:11 GMT+02:00 Chris Murphy <lists@colorremedies.com>:
>> On Sat, May 28, 2016 at 3:42 PM, Peter Becker <floyd.net@gmail.com> wrote:
>>> Thanks for the clarification. I've probably overlooked this.
>>>
>>> But should "resize max" does not do what you expect instead of falling
>>> back on an "invisible" 1?
>>
>> How does it know what the user expects?
>
> Then simply remove the default deviceid und let the user choise what the want.

They can already choose what they want, but they have to specify it,
it's not an interactive UI. Plus the shrink case has to be considered.

What it could do is state what happened rather than completing without
any message, i.e. if devid not specifed it would say something like:

devid 1 resized from X to X

At least there's feedback. It doesn't exactly make sense to require
the most common case, single device, to have to specify the single
device, hence why devid 1 is assumed.


> IMHO its a bad think to choise automaticly a option if its not clear
> what the user wants. And in spezial there is no hint in the output of
> the deviceid who is used.
> The output is:
>
> "Resize '/mnt' of 'max'" .. no hint the this only affect the deviceid
> 1. The suggestion for me is that the whole pool is resized to max.

That would mean the command affects all devid's at the same time. This
would require a lot more logic and safeguards for the shrink case. So
someone would need to do that work. I think such Ux improvements are
happening in a separate github thread on revising the btrfs-progs
UI/Ux.



>
> Possible solutions:
> 1. remove the default deviceid
> 2. resize without deviceid affects the whole pool
> 3. improve the output of the resize command by adding the deviceid
> 4. remove the inconsitent between add+remove and replace by triggering
> resize max after replace is finished.

1 negatively impacts single device setups.
2 doesn't account for shrink, where now every device is reduced by
some unknown amount and could end up a mess in some cases.
3 & 4 are reasonable

Right now the command is rather explicit with an exception for the
single device case. That's really what you're seeing here.


-- 
Chris Murphy