Request for comments about support btrfs in lvresize

Request for comments about support btrfs in lvresize

[Glass Su]

Hi
 I am drafting patches for btrfs support in lvresize command. All things went smoothly until I realized
multi-devices btrfs handling is a little complicated.

For one device btrfs, fslastblock * fsblocksize/FSSIZE is the correct value like ext* and xfs
But for multi-devices btrfs, the two values are whole fs size. The used size of device can be
known by btrfs-progs or superblock read and parse.

Heming suggested that maybe in fs_get_info(), execute of a external script named 
lvresize_btrfs_helper.sh which calls btrfs-progs to gather information is a feasible way.
We both admit it’s not a grace way so here seek advices from you. Thanks.

— 
Su

Re: Request for comments about support btrfs in lvresize

[David Teigland]

On Mon, Mar 10, 2025 at 04:35:54PM +0800, Glass Su wrote:
> Hi
>  I am drafting patches for btrfs support in lvresize command. All things went smoothly until I realized
> multi-devices btrfs handling is a little complicated.

btrfs using multiple devices sounds like an alternative to putting btrfs
on lvm, so is this actually done?

> For one device btrfs, fslastblock * fsblocksize/FSSIZE is the correct value like ext* and xfs
> But for multi-devices btrfs, the two values are whole fs size. The used size of device can be
> known by btrfs-progs or superblock read and parse.

These values are used to calculate fs_last_byte, and that is used:

- by lvextend as a sanity check after the fs resize is done.  So, it could
  be made optional for lvextend.

- by lvreduce to check if the fs has already been sufficiently shrunk, so
  the fs shrink command can be skipped.  Perhaps for btrfs, always require
  the fs shrink command to be run, and always make fs_last_byte large enough
  to do that.

Dave

Re: Request for comments about support btrfs in lvresize

[Glass Su]

> On Mar 11, 2025, at 00:24, David Teigland <teigland@redhat.com> wrote:
> 
> On Mon, Mar 10, 2025 at 04:35:54PM +0800, Glass Su wrote:
>> Hi
>> I am drafting patches for btrfs support in lvresize command. All things went smoothly until I realized
>> multi-devices btrfs handling is a little complicated.
> 
> btrfs using multiple devices sounds like an alternative to putting btrfs
> on lvm, so is this actually done?

Yeah. Btrfs don’t care about the backing device is lv or not. It just treats devices as how ext* and xfs do.
For those people don’t trust btrfs raid stability especially raid56, the use case indeed exits.
> 
>> For one device btrfs, fslastblock * fsblocksize/FSSIZE is the correct value like ext* and xfs
>> But for multi-devices btrfs, the two values are whole fs size. The used size of device can be
>> known by btrfs-progs or superblock read and parse.
> 
> These values are used to calculate fs_last_byte, and that is used:
> 
> - by lvextend as a sanity check after the fs resize is done.  So, it could
>  be made optional for lvextend.
> 
> - by lvreduce to check if the fs has already been sufficiently shrunk, so
>  the fs shrink command can be skipped.  Perhaps for btrfs, always require
>  the fs shrink command to be run, and always make fs_last_byte large enough
>  to do that.

Right. I’ve considered the way making fs_last_byte zero/large enough as `btrfs filesystem resize ` can
handle the newsize rightly. For me, it’s more like a quirk. If it’s acceptable to you I can provide a patchset to implement
the logic, and a testcase, of course.

— 
Su
> 
> Dave
> 

Re: Request for comments about support btrfs in lvresize

[Heming Zhao]

On 3/11/25 09:47, Glass Su wrote:
> 
> 
>> On Mar 11, 2025, at 00:24, David Teigland <teigland@redhat.com> wrote:
>>
>> On Mon, Mar 10, 2025 at 04:35:54PM +0800, Glass Su wrote:
>>> Hi
>>> I am drafting patches for btrfs support in lvresize command. All things went smoothly until I realized
>>> multi-devices btrfs handling is a little complicated.
>>
>> btrfs using multiple devices sounds like an alternative to putting btrfs
>> on lvm, so is this actually done?
> 
> Yeah. Btrfs don’t care about the backing device is lv or not. It just treats devices as how ext* and xfs do.
> For those people don’t trust btrfs raid stability especially raid56, the use case indeed exits.

I feel that few users use btrfs on lvm2 with multiple LVs. because I have
never received any issue related to btrfs on lvm2. And from what I remember,
there are ​not too many users using LVM2 RAID mode either. People ​tend to
prefer using ​mdadm to manage RAID disks (or using hardware raid card).

Anyway, it is ​possible to set up btrfs on LVM2 with multiple LVs, so we
should support this scenario.

- Heming

>>
>>> For one device btrfs, fslastblock * fsblocksize/FSSIZE is the correct value like ext* and xfs
>>> But for multi-devices btrfs, the two values are whole fs size. The used size of device can be
>>> known by btrfs-progs or superblock read and parse.
>>
>> These values are used to calculate fs_last_byte, and that is used:
>>
>> - by lvextend as a sanity check after the fs resize is done.  So, it could
>>   be made optional for lvextend.
>>
>> - by lvreduce to check if the fs has already been sufficiently shrunk, so
>>   the fs shrink command can be skipped.  Perhaps for btrfs, always require
>>   the fs shrink command to be run, and always make fs_last_byte large enough
>>   to do that.
> 
> Right. I’ve considered the way making fs_last_byte zero/large enough as `btrfs filesystem resize ` can
> handle the newsize rightly. For me, it’s more like a quirk. If it’s acceptable to you I can provide a patchset to implement
> the logic, and a testcase, of course.
> 
> —
> Su
>>
>> Dave
>>
> 

Re: Request for comments about support btrfs in lvresize

[David Teigland]

On Tue, Mar 11, 2025 at 09:47:21AM +0800, Glass Su wrote:
> Right. I’ve considered the way making fs_last_byte zero/large enough as `btrfs filesystem resize ` can
> handle the newsize rightly. For me, it’s more like a quirk. If it’s acceptable to you I can provide a patchset to implement
> the logic, and a testcase, of course.

Sure, I can review that.