Re: Request for comments about support btrfs in lvresize

> On Mar 11, 2025, at 00:24, David Teigland <[email protected]> wrote:
>=20
> 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.
>=20
> btrfs using multiple devices sounds like an alternative to putting =
btrfs
> on lvm, so is this actually done?

Yeah. Btrfs don=E2=80=99t care about the backing device is lv or not. It =
just treats devices as how ext* and xfs do.
For those people don=E2=80=99t trust btrfs raid stability especially =
raid56, the use case indeed exits.
>=20
>> 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.
>=20
> These values are used to calculate fs_last_byte, and that is used:
>=20
> - by lvextend as a sanity check after the fs resize is done.  So, it =
could
>  be made optional for lvextend.
>=20
> - 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=E2=80=99ve considered the way making fs_last_byte zero/large =
enough as `btrfs filesystem resize ` can
handle the newsize rightly. For me, it=E2=80=99s more like a quirk. If =
it=E2=80=99s acceptable to you I can provide a patchset to implement
the logic, and a testcase, of course.

=E2=80=94=20
Su
>=20
> Dave
>=20