Hi, please don't resume balance after mount of a btrfs that had its balance interrupted by a system reboot immediately. This way, resume happens while the system is still starting up, which is a fragile process already. Additionally, if the btrfs is in a bad state that makes the balance hang, one does not have a chance to issue a btrfs balance cancel command before the hang happens again. I think a delay of 60 or 120 seconds would be in order. If the resume of a balance process is not logged, please consider doing so as well. Greetings Marc
Use mount option skip_balance https://btrfs.wiki.kernel.org/index.php/Mount_options
That is hard to get into the initramfs for the root filesysem in the encryption case. A delay would be the elegant solution.
Use rootflags=skip_balance as a bit parameter.
s/bit/boot
The delay is not a bad idea from users POV. It can be resumed manually (btrfs balance resume) if it's necessary to start it right after the mount. The immediate start has shown to be rather unpleasant ("you should have used skip_balance"). Suggestions for the delay?
Some systems could take a long time to completely boot and have services running. I'd say 5 minutes as a first stab. I don't know how extensive the configuration needs to be for this, since it's mainly a work around for a crashing bug, correct? The alternative is to just not have an autoresume balance, i.e. always skip_balance, and just expect the user to manually resume?
We could rethink the behaviour: 1) automatic restart on mount, tunable only with skip_balance (current) 2) start after a fixed delay 3) configurable 3.1) filesystem property "restart balance on mount" yes/no 3.2) filesystem property "restart balance on mount after N seconds" We now don't have everything ready for 3, but this sounds as a best option to me.