btrfs balance changes filter on resumption

[CorrosiveTruths]

Hi,

When I resume a paused balance, it adds a usage=90 filter to it.

btrfs bal start -d -m /home
dmesg: BTRFS info (device sda): balance: start -d -m -s
btrfs bal pause /home
dmesg: BTRFS info (device sda): balance: paused
btrfs bal resume /home
BTRFS info (device sda): balance: resume -dusage=90 -musage=90 -susage=90

Same happens with d, or m or their own. it adds the relevant usage filter, dusage=90 / musage=90 susage=90. brtfs bal stat & runtime of the balance both confirm that when it resumes it performs the filtered balance dmesg indicates.

LTS kernel 5.15.77, btrfs-progs v6.0.2

[Zygo]

The current code makes balance resume useless unless the convert or usage filter is specified. On mount, the kernel checks for these filters, and if they are not present, it adds usage=90.

Ideally, the kernel would record the last completed block group's vaddr as the end of a vaddr range (adding a vaddr range filter if there wasn't one before). Then balance would resume exactly where it left off on the next mount.

In most cases it would suffice to simply determine what the highest vaddr is at the start of the balance and keep that one as the upper bound for the vaddr filter, since the current implementation starts at the highest vaddr and works downward, and vaddrs are (almost) never reused by new block groups.

Currently the workaround is to always mount with skip_balance, always cancel the balance after mount, and restart the balance with a filter that does not repeat any work (e.g. the soft flag for convert, or remember the first block group's vaddr when starting the balance and set it manually to resume).

[CorrosiveTruths]

Thanks for explaining, I did think it was very strange that I had these extra parameters after trying to resume.