Re: [PATCH 0/2] btrfs-progs: allowing 2K block size for experimental builds

[David Sterba <dsterba@suse.cz>]

On Thu, Mar 20, 2025 at 08:49:06AM +1030, Qu Wenruo wrote:
> 
> 
> 在 2025/3/20 08:19, David Sterba 写道:
> > On Wed, Feb 26, 2025 at 02:29:13PM +1030, Qu Wenruo wrote:
> >> Btrfs always has its minimal block size as 4K, but that means on the
> >> most common architecture, x86_64, we can not utilize the subpage block
> >> size routine at all.
> >>
> >> Although the future larger folios support will allow us to utilize
> >> subpage routines, the support is still not yet there.
> >>
> >> On the other hand, lowering the block size for experimental/debug builds is
> >> much easier, there is only one major bug (fixed by the first patch) in
> >> btrfs-progs at least.
> >>
> >> Kernel sides enablement is not huge either, but it has dependency on
> >> the subpage related backlog patches to pass most fstests, which is not small.
> >>
> >> However since we're not pushing this 2K block size for end users, we can
> >> accept some limitations on the 2K block size support:
> >>
> >> - No 2K node size mkfs support
> >>    This is mostly caused by how we create the initial temporaray fs.
> >>    The initial temporaray fs contains at least 6 root items.
> >>    But one root item is 439 bytes, we need a level 1 root tree for the
> >>    initial temporaray fs.
> >>
> >>    But we do not support multi-level trees for the initial fs, thus no
> >>    such support for now.
> >>
> >> - No mixed block groups mkfs support
> >>    Caused by the missing 2K node size support
> >>
> >> Qu Wenruo (3):
> >>    btrfs-progs: fix the incorrect buffer size for super block
> >>    btrfs-progs: support 2k block size
> >>    btrfs-progs: convert: check the sectorsize against BTRFS_MIN_BLOCKSIZE
> > 
> > Thanks, added to devel. I've enabled the 2k case for convert but it
> > fails, I haven't analyzed it as it does not seem to be important right
> > now.
> 
> 2K convert needs the ext4 to use 2K block size too, which is only 
> lightly tested here.

So the failure I was observing was because I extended ext2 test (001),
ext4 works.

> E.g. at least it works here:
> 
> ./btrfs-convert ~/test.img
> btrfs-convert from btrfs-progs v6.12
> 
> WARNING: blocksize 2048 is not equal to the page size 4096, converted 
> filesystem won't mount on this system
> Source filesystem:
>    Type:           ext2
>    Label:
>    Blocksize:      2048
>    UUID:           e004c54c-7a86-4c71-be87-a8ff707c3948
> Target filesystem:
>    Label:
>    Blocksize:      2048
>    Nodesize:       16384
>    UUID:           b54b8947-7f7a-4e3b-a658-d344a1d47766
>    Checksum:       crc32c
>    Features:       extref, skinny-metadata, no-holes, free-space-tree 
> (default)
>      Data csum:    yes
>      Inline data:  yes
>      Copy xattr:   yes
> Reported stats:
>    Total space:      5368709120
>    Free space:       4693164032 (87.42%)
>    Inode count:          327680
>    Free inodes:          327668
>    Block count:         2621440
> Create initial btrfs filesystem
> Create ext2 image file
> Create btrfs metadata
> Copy inodes [o] [         0/        12]
> Free space cache cleared
> Conversion complete
> 
> But it should not be considered a feature for end users.

Agreed.