btrfs-convert gives "tree block not nodesize aligned" kernel warning, that is not fixable even after LV partition re-alignment and multiple btrfs-balances

[infinity0]

I recently converted a ext4 FS inside a LVM2 container into btrfs (as part of #1064, but that issue is unrelated to this). Upon mounting it I got the following kernel warning:

[  +0.000271] BTRFS warning (device dm-13): tree block not nodesize aligned, start 285174702080 nodesize 16384, can be resolved by a full metadata balance

This warning was originally added here by @adam900710 it seems, to prepare for some future scenario that I don't understand.

The problem persists even after I tried the following, in sequence:

• btrfs balance (full)
• btrfs balance -m, about 20 times
• manually defragmenting my LVM container so that all LVs are contiguous and aligned with each other, using pvmove (and lvm2defrag even though that is buggy and only gets the job half-done, the remainder done manually)
• subsequent shrinking, growing, btrfs check, btrfs scrub, balance (full) and balance -m all over yet again

btrfs scrub gives no errors, btrfs check gives the following:

...
WARNING: tree block [362473218048, 362473234432) is not nodesize aligned, may cause problem for 64K page system
WARNING: tree block [362473234432, 362473250816) is not nodesize aligned, may cause problem for 64K page system
WARNING: tree block [362473250816, 362473267200) is not nodesize aligned, may cause problem for 64K page system
WARNING: chunk[359127375872 360201117696) is not fully aligned to BTRFS_STRIPE_LEN (65536)
WARNING: chunk[360201117696 361274859520) is not fully aligned to BTRFS_STRIPE_LEN (65536)
WARNING: chunk[361274859520 362348601344) is not fully aligned to BTRFS_STRIPE_LEN (65536)
WARNING: chunk[362348601344 363422343168) is not fully aligned to BTRFS_STRIPE_LEN (65536)
WARNING: chunk[363422343168 364496084992) is not fully aligned to BTRFS_STRIPE_LEN (65536)
...

Also, every time I run a balance the numbers go up, e.g. the kernel warnings now say:

[  +0.000254] BTRFS warning (device dm-13): tree block not nodesize aligned, start 364497592320 nodesize 16384, can be resolved by a full metadata balance

I do not have this issue with any of my other btrfs filesystems that I also converted with btrfs-convert, although those were done using a version from a few years ago. After manual defrag, the LVM container has the following device-mapper tables:

# logical start, size, type, "physical" start
0 2147483648 linear 9:1 2048
0 3221225472 linear 9:1 2147485696
0 167772160 linear 9:1 5368711168
0 67108864 linear 9:1 5536483328

The offending LV is the 3rd one that starts at 5368711168. But all of these LVs have a physical start that = 2048 (mod 16384) (my nodesize), so I don't understand why only the 3rd LV is (still) giving these kernel warnings.

>>> [(x - 2048) / 16384 for x in [2048, 2147485696, 5368711168, 5536483328]]
[0.0, 131072.0, 327680.0, 337920.0]

Should I just ignore these warnings? Is it a false positive? Is it fixable?

[infinity0]

The solution was to manually defragment my LVs using pvmove - the kernel warnings went away afterwards.

Er, I spoke too soon, the warnings are still occurring even after a full balance. The previous "warning went away" was for a different device and I got confused. The warnings do not occur with other LVs in the same LVM container; I will update the OP to reflect that this is a real bug.

[forestbeasts]

We've got the same warnings over here with no LVM involved at all (btrfs-progs 6.17.1). Just btrfs on LUKS on bare metal.

Tried a full metadata rebalance (after converting the metadata to DUP... which broke the filesystem hard because it ran out of space, that took some work to fix), it didn't hurt but it also didn't really help.

-- Ylfingr

[adam900710]

The problem is the chunk itself is not fully aligned to 64K (caused by btrfs-convert), thus making tree blocks inside that chunk not aligned.
Underlying LVM setup is not related.
Btrfs don't know the underlying extents of LVM, it just see a single large block device (LV).

It will need several different fixes.

For btrfs-convert, do more chunk alignment checks, at the cost of more strict free space requirement. (Fragmented ext* fs will be rejected more frequently)

For kernel, do more alignment check when allocating both chunks and dev-extents. This will cause some extra holes for dev-extents, thus may trigger more ENOSPC for those converted fs with unaligned chunks.

Unfortunately they are not high priority items (only affects converted fs, and has some bad impact), thus will not be fixed any time soon.

If you don't care about 64K page sized system, just ignore it.
If you care about 64K page sized system, or really want the warnings to be gone, create a new btrfs and copy the data will be the best solution.the

Remember, btrfs-convert is still going to have some extra limits/hacks compared to pure btrfs.

[infinity0]

OK it sounds like the devs are roughly aware of what is the cause behind this. I have already created a fresh copy of the FS and the warnings are indeed gone. I am eager to delete the old FS to reclaim the space - please let me know if you would like me to run any diagnostics etc for this bug, before I go ahead and delete it in the next few weeks/months.

[adam900710]

Feel free to delete the original fs, the important things are already shown in the btrfs check result.