Re: [PATCH RFC] btrfs: exit scrub and balance early if the fs is being frozen

[Qu Wenruo <wqu@suse.com>]

在 2025/7/7 22:00, David Sterba 写道:
> On Mon, Jul 07, 2025 at 02:53:58PM +0930, Qu Wenruo wrote:
>>> Reason for RFC:
>>> I'm not sure if cancelling is the best solution, but it is the easiest
>>> one to implementation.
>>>
>>> Pause the scrub/balance is not really feasible yet, as it will still hold the
>>> mnt_want_write_file(), thus blocking freezing.
>>>
>>> Meanwhile for end users, pausing scrub/balance when freezing, and resume
>>> when thawing should be the best outcome.
>>
>> I have explored some other solutions, like dropping and grabbing the
>> s_writers.rw_sem during the balance/scrub.
>>
>> The problem of that solution is the reserved lock sequence, thus it will
>> be deadlock prune.
> 
> What do you mean by 'reserved lock sequence'?


The s_umount and s_writers.rw_sem are always locked way before any btrfs 
specific locks.

If you unhold the s_writers.rw_sem, it's very easy to cause ABBA lock 
sequence thus lockdep warnings.


> 
>> Currently I guess the best solution would be introducing a special error
>> code (maybe >0? -EGAIN may be a little too generic in this case) so that
>> if we hit that specific error code, we error out as usual.
>>
>> But at the top level where we call mnt_want_write*() function, we drop
>> the rw_sem, and retry other than exit.
>>
>> By this, we split the original long-running ioctl into several different
>> smaller sections (the split only happens after the fs being frozen), so
>> that they can properly follow the fs freeze behavior.
> 
> We have cancellable balance and scrub so there are checkpoints that can
> be extended to also handle freezing in a way that pauses the operation
> and waits until unfreeze. The sequence "drop locks/freeze/take locks"
> should work.

It will cause deadlock if you drop the lock then re-lock with any btrfs 
specific lock hold.

You have to return to where we call mnt_want_write_file() to unlock, 
thus meaning a much different resume path.

> For the exclusive ops it's guaranteed nothing else will
> start so the state will remain the same.
> 
>> The challenge is how to resume from such interruption.
>> Currently neither scrub nor balance can properly handle such resume and
>> will restart from the beginning.
>>
>> And even with that resume implementation, the checks in this patch will
>> still be needed.
> 
> The checks peek into the interals of the freezing mechanism, which I
> think is not the right.

Nope, that's completely common.

f2fs is already doing that to skip its background gc.

Thanks,
Qu