From: David Sterba <dsterba@suse.cz>
To: Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH RFC] btrfs: exit scrub and balance early if the fs is being frozen
Date: Mon, 7 Jul 2025 14:25:57 +0200 [thread overview]
Message-ID: <20250707122557.GD4453@twin.jikos.cz> (raw)
In-Reply-To: <9606fae20bff6c1fbe14dc7b067f3b333c2a955b.1751847905.git.wqu@suse.com>
On Mon, Jul 07, 2025 at 09:55:12AM +0930, Qu Wenruo wrote:
> [PROBLEM]
> There are some reports that btrfs is unable to be frozen if there is a
> running scrub.
>
> [CAUSE]
> If there is a running scrub, freeze_super() will wait for the running
> scrub as read-write scrub is holding sb_start_write():
>
> Scrub process | Freeze process
> -------------------------------------+--------------------------------
> btrfs_ioctl_scrub() |
> |- mnt_want_write_file() |
> | |- sb_start_write() |
> | This will block freezing |
> | | freeze_super()
> |- mnt_drop_write_file() | |
> | |- sb_wait_write()
> | | This will wait for any
> | | sb_start_write() to finish
>
> This means freeze_super() will wait for any running scrub to finish.
> The same applies to all ioctls that requires mnt_want_write_file().
>
> The most common long running ones are scrub and balance.
>
> Since scrub and balance can be very long running operations, this will
> cause freezing to timeout.
> And since freezing the fs is required before suspension/hibernation,
> this means those two operations will fail too.
>
> [FIX]
> Check if the fs is being frozen, and if so cancel the current running
> scrub or balance.
>
> So far I didn't find a better way to solve the problem, the only way to
> drop the mnt_want_write_file() is to finish or cancel the scrub/balance.
>
> There is no way to drop the mnt_want_write_file() meanwhile just pausing
> scrub/balance, at least not for now.
>
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> ---
> Reason for RFC:
> I'm not sure if cancelling is the best solution, but it is the easiest
> one to implementation.
I don't think it's a good solution to cancel the operations, in case of
scrub like the most likely to run during freezing it's possible to do
the pause, drop and continue after unfreezing.
I haven't looked how this could be done for balance, possibly in a
similar way. And for trim.
> 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.
Pausing the operations and keeping the in-memory state is easiest from
the POV of restarting the operation. Restarting from that exact point
from user space would be harder as there's no complete information
communicated back and the tools are not saving it anywhere.
next prev parent reply other threads:[~2025-07-07 12:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-07 0:25 [PATCH RFC] btrfs: exit scrub and balance early if the fs is being frozen Qu Wenruo
2025-07-07 5:23 ` Qu Wenruo
2025-07-07 12:30 ` David Sterba
2025-07-07 12:37 ` Daniel Vacek
2025-07-07 22:16 ` Qu Wenruo
2025-07-07 12:25 ` David Sterba [this message]
2025-10-12 8:23 ` Askar Safin
2025-10-12 23:56 ` Qu Wenruo
2025-10-15 4:05 ` Askar Safin
2025-10-15 7:00 ` Qu Wenruo
2025-10-15 7:59 ` Askar Safin
2025-10-15 8:07 ` Qu Wenruo
2025-10-15 11:12 ` Askar Safin
2025-10-15 23:01 ` Qu Wenruo
2025-10-16 8:40 ` Askar Safin
2025-10-16 9:46 ` Qu Wenruo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250707122557.GD4453@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=wqu@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox