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

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

[Qu Wenruo]

[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.

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.
---
 fs/btrfs/relocation.c | 3 ++-
 fs/btrfs/scrub.c      | 6 ++++++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 175fc3acc38b..f173e36a69f8 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -2797,7 +2797,8 @@ noinline int btrfs_should_cancel_balance(const struct btrfs_fs_info *fs_info)
 {
 	return atomic_read(&fs_info->balance_cancel_req) ||
 		atomic_read(&fs_info->reloc_cancel_req) ||
-		fatal_signal_pending(current);
+		fatal_signal_pending(current) ||
+		fs_info->sb->s_writers.frozen > SB_UNFROZEN;
 }
 ALLOW_ERROR_INJECTION(btrfs_should_cancel_balance, TRUE);
 
diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index 6776e6ab8d10..bf8e4c411b60 100644
--- a/fs/btrfs/scrub.c
+++ b/fs/btrfs/scrub.c
@@ -2244,6 +2244,12 @@ static int scrub_simple_mirror(struct scrub_ctx *sctx,
 		u64 found_logical = U64_MAX;
 		u64 cur_physical = physical + cur_logical - logical_start;
 
+		/* Fs being frozen, need to exit early or freezing will timeout. */
+		if (fs_info->sb->s_writers.frozen > SB_UNFROZEN) {
+			ret = -ECANCELED;
+			break;
+		}
+
 		/* Canceled? */
 		if (atomic_read(&fs_info->scrub_cancel_req) ||
 		    atomic_read(&sctx->cancel_req)) {
-- 
2.50.0

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

[Qu Wenruo]

在 2025/7/7 09:55, Qu Wenruo 写道:
> [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.
> 
> 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.


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.

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.

Thanks,
Qu

> ---
>   fs/btrfs/relocation.c | 3 ++-
>   fs/btrfs/scrub.c      | 6 ++++++
>   2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
> index 175fc3acc38b..f173e36a69f8 100644
> --- a/fs/btrfs/relocation.c
> +++ b/fs/btrfs/relocation.c
> @@ -2797,7 +2797,8 @@ noinline int btrfs_should_cancel_balance(const struct btrfs_fs_info *fs_info)
>   {
>   	return atomic_read(&fs_info->balance_cancel_req) ||
>   		atomic_read(&fs_info->reloc_cancel_req) ||
> -		fatal_signal_pending(current);
> +		fatal_signal_pending(current) ||
> +		fs_info->sb->s_writers.frozen > SB_UNFROZEN;
>   }
>   ALLOW_ERROR_INJECTION(btrfs_should_cancel_balance, TRUE);
>   
> diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
> index 6776e6ab8d10..bf8e4c411b60 100644
> --- a/fs/btrfs/scrub.c
> +++ b/fs/btrfs/scrub.c
> @@ -2244,6 +2244,12 @@ static int scrub_simple_mirror(struct scrub_ctx *sctx,
>   		u64 found_logical = U64_MAX;
>   		u64 cur_physical = physical + cur_logical - logical_start;
>   
> +		/* Fs being frozen, need to exit early or freezing will timeout. */
> +		if (fs_info->sb->s_writers.frozen > SB_UNFROZEN) {
> +			ret = -ECANCELED;
> +			break;
> +		}
> +
>   		/* Canceled? */
>   		if (atomic_read(&fs_info->scrub_cancel_req) ||
>   		    atomic_read(&sctx->cancel_req)) {

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

[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'?

> 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. 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.

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

[Daniel Vacek]

On Mon, 7 Jul 2025 at 14:30, David Sterba <dsterba@suse.cz> wrote:
>
> 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'?

That's a typo - reversed

> > 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. 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.
>

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

[Qu Wenruo]

在 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

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

[David Sterba]

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.

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

[Askar Safin]

Qu Wenruo <wqu@suse.com>:
> There are some reports that btrfs is unable to be frozen if there is a

I tested your patch on real hardware.

I applied it to current Linux mainline.

I have btrfs-raid on two big disks.

I started "sudo btrfs scrub start -B -d /" and pressed "Suspend" in GUI.

If /sys/power/freeze_filesystems is 0 (this is default), then your patch doesn't work.

If /sys/power/freeze_filesystems is 1, then the system stops to respond for a minute
and then suspends. Here is journalctl:
https://zerobin.net/?e3376d7d056dcb04#LyzGFYeVdWsbZfgC25G4TuSct6QDyZ278gQlZgCfR94= .

As well as I understand from journalctl, systemd tries to freeze userspace
process "btrfs scrub" and fails. Then systemd times out after a minute,
and then suspend proceeds.

So, in short, this is not complete solution yet.

Also I tested Sterba's patch, and it doesn't work either:
https://lore.kernel.org/linux-btrfs/20250720194803.3661-1-safinaskar@zohomail.com/ .

I really want this bug to be fixed. Please, CC me with your future attempts.

-- 
Askar Safin

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

[Qu Wenruo]

在 2025/10/12 18:53, Askar Safin 写道:
> Qu Wenruo <wqu@suse.com>:
>> There are some reports that btrfs is unable to be frozen if there is a
> 
> I tested your patch on real hardware.
> 
> I applied it to current Linux mainline.
> 
> I have btrfs-raid on two big disks.
> 
> I started "sudo btrfs scrub start -B -d /" and pressed "Suspend" in GUI.
> 
> If /sys/power/freeze_filesystems is 0 (this is default), then your patch doesn't work.
> 
> If /sys/power/freeze_filesystems is 1, then the system stops to respond for a minute
> and then suspends. Here is journalctl:
> https://zerobin.net/?e3376d7d056dcb04#LyzGFYeVdWsbZfgC25G4TuSct6QDyZ278gQlZgCfR94= .
> 
> As well as I understand from journalctl, systemd tries to freeze userspace
> process "btrfs scrub" and fails. Then systemd times out after a minute,
> and then suspend proceeds.
> 
> So, in short, this is not complete solution yet.
> 
> Also I tested Sterba's patch, and it doesn't work either:
> https://lore.kernel.org/linux-btrfs/20250720194803.3661-1-safinaskar@zohomail.com/ .
> 
> I really want this bug to be fixed. Please, CC me with your future attempts.

I'll send you new experimental patch(es) first for test.

In fact I already have some idea how to address it, but unfortunately it 
may take some time.

And it will address scrub first, then addressing balance related operations.

Thanks,
Qu
> 

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

[Askar Safin]

On Mon, Oct 13, 2025 at 2:56 AM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
> I'll send you new experimental patch(es) first for test.
Thank you!
Also, I tested your patch on my distro's version of btrfs-progs. If
you want, I can retest on new one.


-- 
Askar Safin

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

[Qu Wenruo]

[-- Attachment #1: Type: text/plain, Size: 2732 bytes --]



在 2025/10/12 18:53, Askar Safin 写道:
> Qu Wenruo <wqu@suse.com>:
>> There are some reports that btrfs is unable to be frozen if there is a
> 
> I tested your patch on real hardware.
> 
> I applied it to current Linux mainline.
> 
> I have btrfs-raid on two big disks.
> 
> I started "sudo btrfs scrub start -B -d /" and pressed "Suspend" in GUI.
> 
> If /sys/power/freeze_filesystems is 0 (this is default), then your patch doesn't work.

In that case, the problem is my patch only checks if the fs is being 
frozen. And if suspension doesn't need to freeze the fs, it will not work.

> 
> If /sys/power/freeze_filesystems is 1, then the system stops to respond for a minute
> and then suspends. Here is journalctl:
> https://zerobin.net/?e3376d7d056dcb04#LyzGFYeVdWsbZfgC25G4TuSct6QDyZ278gQlZgCfR94= .

Btrfs detects the freezing request, and canceled the run, so that part 
is working:

   Oct 12 10:56:08 comp kernel: BTRFS info (device nvme1n1p1): scrub: 
not finished on devid 1 with status: -125
   Oct 12 10:56:08 comp kernel: BTRFS info (device nvme1n1p1): scrub: 
not finished on devid 2 with status: -125

And since we canceled the run, the ioctl returned, thus all user space 
programs can be frozen:

   Oct 12 10:56:08 comp kernel: Freezing user space processes
   Oct 12 10:56:08 comp kernel: Freezing user space processes completed 
(elapsed 0.001 seconds)

Unfortunately the delay (19s) between the freeze request may not be 
reduced any further, the current check timing is for each full stripe (64K).

Maybe we can reduce the number of running stripes in the future.

But you experienced a full 60s, which I can not explain.

> 
> As well as I understand from journalctl, systemd tries to freeze userspace
> process "btrfs scrub" and fails. Then systemd times out after a minute,
> and then suspend proceeds.
> 
> So, in short, this is not complete solution yet.

Please try the attached patch, the idea is still based on the older 
patch, but now added the extra check for user space process freezing checks.
Thus it should still work without freeze_filesystems set to 1.


BTW, since the user space process freezing part require the process to 
exit to user space, it means pausing is not feasible, as pausing is 
still waiting inside kernel space, thus will not work.


Unfortunately that patch is only taking scrub into consideration, thus 
please do not test any relocation yet.

Thanks,
Qu

> 
> Also I tested Sterba's patch, and it doesn't work either:
> https://lore.kernel.org/linux-btrfs/20250720194803.3661-1-safinaskar@zohomail.com/ .
> 
> I really want this bug to be fixed. Please, CC me with your future attempts.
> 

[-- Attachment #2: 0001-btrfs-cancel-the-scrub-if-the-fs-or-the-process-is-b.patch --]
[-- Type: text/x-patch, Size: 2724 bytes --]

From a618627b6bf316b64a8b0b2a289dab0c8a01b485 Mon Sep 17 00:00:00 2001
Message-ID: <a618627b6bf316b64a8b0b2a289dab0c8a01b485.1760510930.git.wqu@suse.com>
From: Qu Wenruo <wqu@suse.com>
Date: Wed, 15 Oct 2025 17:07:00 +1030
Subject: [PATCH] btrfs: cancel the scrub if the fs or the process is being
 frozen

It's a known bug that btrfs scrub/dev-replace can prevent the fs from
suspending.

There are at least two factors involved:

- Holding super_block::s_writers for the whole scrub/dev-replace
  duration
  We hold that mutex through mnt_want_write_file() for the whole
  scrub/dev-replace duration.

  That will prevent the fs being frozen.
  It's tunable for the kernel to suspend the fs before suspending, if
  that's the case, btrfs will refuse to freeze and break the suspension.

- Stuck in kernel space for a long time
  During suspension all user progresses (and some kernel threads) will
  be frozen.
  But if a user space progress has fallen into kernel and do not return
  for a long time, it will make suspension to time out.

  Unfortunately scrub/dev-replace is a long running ioctl, and it will
  prevent the btrfs-progs from returning to user space.

Address them in one go:

- Introduce a new helper should_cancel_scrub()
  Which checks both fs and process freezing.

- Cancel the run if should_cancel_scrub() is true
  The check is done at scrub_simple_mirror() and
  scrub_raid56_parity_stripe().

  Unfortunately canceling is the only feasible solution here, pausing is
  not possible as we will still stay in the kernel state thus will still
  prevent the process from being frozen.

Signed-off-by: Qu Wenruo <wqu@suse.com>
---
 fs/btrfs/scrub.c | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index fe266785804e..cd6c70c37076 100644
--- a/fs/btrfs/scrub.c
+++ b/fs/btrfs/scrub.c
@@ -2234,6 +2234,18 @@ static int scrub_raid56_parity_stripe(struct scrub_ctx *sctx,
 	return ret;
 }
 
+static bool should_cancel_scrub(struct btrfs_fs_info *fs_info)
+{
+	/*
+	 * If some one is trying to freeze the fs or the scrub process,
+	 * cancel the run.
+	 */
+	if (fs_info->sb->s_writers.frozen > SB_UNFROZEN ||
+	    freezing(current))
+		return true;
+	return false;
+}
+
 /*
  * Scrub one range which can only has simple mirror based profile.
  * (Including all range in SINGLE/DUP/RAID1/RAID1C*, and each stripe in
@@ -2263,7 +2275,8 @@ static int scrub_simple_mirror(struct scrub_ctx *sctx,
 
 		/* Canceled? */
 		if (atomic_read(&fs_info->scrub_cancel_req) ||
-		    atomic_read(&sctx->cancel_req)) {
+		    atomic_read(&sctx->cancel_req) ||
+		    should_cancel_scrub(fs_info)) {
 			ret = -ECANCELED;
 			break;
 		}
-- 
2.50.1

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

[Askar Safin]

On Wed, Oct 15, 2025 at 10:00 AM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
> Unfortunately the delay (19s) between the freeze request may not be
> reduced any further, the current check timing is for each full stripe (64K).

Personally I'm okay with 19s delay. But less is better, of course.

> But you experienced a full 60s, which I can not explain.

First systemd tries to freeze unit "user.slice", and then it seems to
perform kernel sleep:

Oct 12 10:54:49 comp wpa_supplicant[1108]: nl80211: deinit
ifname=wlp0s20f3 disabled_11b_rates=0
Oct 12 10:54:58 comp systemd[1]: NetworkManager-dispatcher.service:
Deactivated successfully.
Oct 12 10:55:49 comp systemd-sleep[2191]: Failed to freeze unit
'user.slice': Connection timed out

systemd tries to freeze that slice and then times out after 60s.

And I think that 60s is unacceptable delay.

> Please try the attached patch, the idea is still based on the older

I will try. Hopefully today. Thank you!

> Thus it should still work without freeze_filesystems set to 1.

Kernel devs plan to make freeze_filesystems=1 default.
So we should not care about freeze_filesystems=0 case at all.
I'm okay with manually setting it to 1 (and it will be 1 by default anyway).
See https://lore.kernel.org/all/20250402-work-freeze-v2-3-6719a97b52ac@kernel.org/

> please do not test any relocation yet.
I don't use relocations. The only operations I use are scrub and trim.

Also, I noticed that poweroff takes a lot of time if scrub is running inside
of systemd service. Systemd is unable to properly terminate that service.
Systemd tries a lot of time, then times out, then poweroff reaches
"systemd-shutdown" stage (which is very late poweroff stage),
then "systemd-shutdown" again tries to kill "btrfs scrub" and then
(after lots of time, again) the system finally powers off.

-- 
Askar Safin

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

[Qu Wenruo]

在 2025/10/15 18:29, Askar Safin 写道:
> On Wed, Oct 15, 2025 at 10:00 AM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>> Unfortunately the delay (19s) between the freeze request may not be
>> reduced any further, the current check timing is for each full stripe (64K).
> 
> Personally I'm okay with 19s delay. But less is better, of course.
> 
>> But you experienced a full 60s, which I can not explain.
> 
> First systemd tries to freeze unit "user.slice", and then it seems to
> perform kernel sleep:
> 
> Oct 12 10:54:49 comp wpa_supplicant[1108]: nl80211: deinit
> ifname=wlp0s20f3 disabled_11b_rates=0
> Oct 12 10:54:58 comp systemd[1]: NetworkManager-dispatcher.service:
> Deactivated successfully.
> Oct 12 10:55:49 comp systemd-sleep[2191]: Failed to freeze unit
> 'user.slice': Connection timed out
> 
> systemd tries to freeze that slice and then times out after 60s.
> 
> And I think that 60s is unacceptable delay.
> 
>> Please try the attached patch, the idea is still based on the older
> 
> I will try. Hopefully today. Thank you!
> 
>> Thus it should still work without freeze_filesystems set to 1.
> 
> Kernel devs plan to make freeze_filesystems=1 default.
> So we should not care about freeze_filesystems=0 case at all.
> I'm okay with manually setting it to 1 (and it will be 1 by default anyway).
> See https://lore.kernel.org/all/20250402-work-freeze-v2-3-6719a97b52ac@kernel.org/
> 
>> please do not test any relocation yet.
> I don't use relocations. The only operations I use are scrub and trim.
> 
> Also, I noticed that poweroff takes a lot of time if scrub is running inside
> of systemd service. Systemd is unable to properly terminate that service.
> Systemd tries a lot of time, then times out, then poweroff reaches
> "systemd-shutdown" stage (which is very late poweroff stage),
> then "systemd-shutdown" again tries to kill "btrfs scrub" and then
> (after lots of time, again) the system finally powers off.

This is another problem, that scrub doesn't check pending signals at 
all, unlike relocation which does the proper signal check.

If the test patch works for you, I'll send out a series addressing all 
problems:

- Delay
   By reducing the number of full stripes from 128 to 16 or 8.

- Add extra signal checks

- The suspension fix

Thanks,
Qu
> 

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

[Askar Safin]

I just noticed that suspend behavior depends on whether "btrfs scrub" is
started in terminal window or as a systemd service. I think this is because
systemd tries to freeze user session when suspending, but doesn't freeze
services.

So I retested everything.

All tests were done with my distro's version of btrfs-progs (6.14-1).
My distro is Debian Trixie.
I have btrfs raid-1, which spans two actual partitions, 3.5 TiB each.

Let's start with unpatched v6.18-rc1.

- scrub in win, freeze_filesystems=0 - suspend doesn't work

- scrub as a service, freeze_filesystems=0 - suspend doesn't work

- scrub in win, freeze_filesystems=1
suspend takes 6-10 mins. I. e. the system hangs for 6-10 mins and then
suspends. I suspect this is time needed to complete scrub

- scrub as a service, freeze_filesystems=1 - the same

Also: on unpatched kernel "btrfs scrub" terminates instantly if it receives
INT, but doesn't terminate if it receives KILL, TERM or HUP.

Now v6.18-rc1 with your old 7 Jul 2025 patch
( https://lore.kernel.org/linux-btrfs/9606fae20bff6c1fbe14dc7b067f3b333c2a955b.1751847905.git.wqu@suse.com/ ).

- scrub in win, freeze_filesystems=0 - suspend doesn't work

- scrub as a service, freeze_filesystems=0 - suspend doesn't work

- scrub in win, freeze_filesystems=1
suspend takes 1 min. I. e. the system hangs for 1 min, then suspends

- scrub as a service, freeze_filesystems=1
suspend works perfectly. I. e. the system instantly suspends. I don't even
notice 19s delay you are talking about

Now v6.18-rc1 with your new 15 Oct 2025 patch
( https://lore.kernel.org/linux-btrfs/8c3628d5-8fce-45a1-b29c-65c2c52f1c06@gmx.com/ ).

- scrub in win, freeze_filesystems=0 - hangs for 60s, then suspends

- scrub as a service, freeze_filesystems=0 - works perfectly, i. e. suspends instantly

- scrub in win, freeze_filesystems=1 - hangs for 60s, then suspends
here is journalctl: https://zerobin.net/?7b394069a9050b8d#7PrnCDJV2t9inNFS3/EhxHJUS24iSGX7FAmjUstKKr4=

- scrub as a service, freeze_filesystems=1 - works perfectly, i. e. suspends instantly

-- 
Askar Safin

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

[Qu Wenruo]

[-- Attachment #1: Type: text/plain, Size: 3062 bytes --]



在 2025/10/15 21:42, Askar Safin 写道:
> I just noticed that suspend behavior depends on whether "btrfs scrub" is
> started in terminal window or as a systemd service. I think this is because
> systemd tries to freeze user session when suspending, but doesn't freeze
> services.

I don't think it's the case, as the pm suspend-to-ram requires all user 
space programs to be frozen.

I guess the difference is in the systemd's handling of user slice.
Maybe it is sending some signal first, then freeze for the time-out 
case, but directly freeze for the service.

Anyway, mind to test the attached newer patch?

This one also adds the extra signal checking (including the regular 
SIGINT and fatal ones), hope it would be the last testing patch.

Please apply it upon clean upstream branch (aka, no previous test 
patches applied).


But if the latest patch doesn't work, I'm running out of ideas.
Inside the kernel I can only find out how to check signals and freezing 
status, but if systemd is not using those two ways, I have no more ideas.

Thanks,
Qu

> 
> So I retested everything.
> 
> All tests were done with my distro's version of btrfs-progs (6.14-1).
> My distro is Debian Trixie.
> I have btrfs raid-1, which spans two actual partitions, 3.5 TiB each.
> 
> Let's start with unpatched v6.18-rc1.
> 
> - scrub in win, freeze_filesystems=0 - suspend doesn't work
> 
> - scrub as a service, freeze_filesystems=0 - suspend doesn't work
> 
> - scrub in win, freeze_filesystems=1
> suspend takes 6-10 mins. I. e. the system hangs for 6-10 mins and then
> suspends. I suspect this is time needed to complete scrub
> 
> - scrub as a service, freeze_filesystems=1 - the same
> 
> Also: on unpatched kernel "btrfs scrub" terminates instantly if it receives
> INT, but doesn't terminate if it receives KILL, TERM or HUP.
> 
> Now v6.18-rc1 with your old 7 Jul 2025 patch
> ( https://lore.kernel.org/linux-btrfs/9606fae20bff6c1fbe14dc7b067f3b333c2a955b.1751847905.git.wqu@suse.com/ ).
> 
> - scrub in win, freeze_filesystems=0 - suspend doesn't work
> 
> - scrub as a service, freeze_filesystems=0 - suspend doesn't work
> 
> - scrub in win, freeze_filesystems=1
> suspend takes 1 min. I. e. the system hangs for 1 min, then suspends
> 
> - scrub as a service, freeze_filesystems=1
> suspend works perfectly. I. e. the system instantly suspends. I don't even
> notice 19s delay you are talking about
> 
> Now v6.18-rc1 with your new 15 Oct 2025 patch
> ( https://lore.kernel.org/linux-btrfs/8c3628d5-8fce-45a1-b29c-65c2c52f1c06@gmx.com/ ).
> 
> - scrub in win, freeze_filesystems=0 - hangs for 60s, then suspends
> 
> - scrub as a service, freeze_filesystems=0 - works perfectly, i. e. suspends instantly
> 
> - scrub in win, freeze_filesystems=1 - hangs for 60s, then suspends
> here is journalctl: https://zerobin.net/?7b394069a9050b8d#7PrnCDJV2t9inNFS3/EhxHJUS24iSGX7FAmjUstKKr4=
> 
> - scrub as a service, freeze_filesystems=1 - works perfectly, i. e. suspends instantly
> 

[-- Attachment #2: 0001-btrfs-cancel-the-scrub-if-the-fs-or-the-process-is-b.patch --]
[-- Type: text/x-patch, Size: 2817 bytes --]

From e56bff151de2c98ad489ab0721b1d68e58b45129 Mon Sep 17 00:00:00 2001
Message-ID: <e56bff151de2c98ad489ab0721b1d68e58b45129.1760569187.git.wqu@suse.com>
From: Qu Wenruo <wqu@suse.com>
Date: Wed, 15 Oct 2025 17:07:00 +1030
Subject: [PATCH] btrfs: cancel the scrub if the fs or the process is being
 frozen

It's a known bug that btrfs scrub/dev-replace can prevent the fs from
suspending.

There are at least two factors involved:

- Holding super_block::s_writers for the whole scrub/dev-replace
  duration
  We hold that mutex through mnt_want_write_file() for the whole
  scrub/dev-replace duration.

  That will prevent the fs being frozen.
  It's tunable for the kernel to suspend the fs before suspending, if
  that's the case, btrfs will refuse to freeze and break the suspension.

- Stuck in kernel space for a long time
  During suspension all user progresses (and some kernel threads) will
  be frozen.
  But if a user space progress has fallen into kernel and do not return
  for a long time, it will make suspension to time out.

  Unfortunately scrub/dev-replace is a long running ioctl, and it will
  prevent the btrfs-progs from returning to user space.

Address them in one go:

- Introduce a new helper should_cancel_scrub()
  Which checks both fs and process freezing.

- Cancel the run if should_cancel_scrub() is true
  The check is done at scrub_simple_mirror() and
  scrub_raid56_parity_stripe().

  Unfortunately canceling is the only feasible solution here, pausing is
  not possible as we will still stay in the kernel state thus will still
  prevent the process from being frozen.

Signed-off-by: Qu Wenruo <wqu@suse.com>
---
 fs/btrfs/scrub.c | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index fe266785804e..1ddcd8a88610 100644
--- a/fs/btrfs/scrub.c
+++ b/fs/btrfs/scrub.c
@@ -2234,6 +2234,22 @@ static int scrub_raid56_parity_stripe(struct scrub_ctx *sctx,
 	return ret;
 }
 
+static bool should_cancel_scrub(struct btrfs_fs_info *fs_info)
+{
+	/*
+	 * If some one is trying to freeze the fs or the scrub process,
+	 * cancel the run.
+	 */
+	if (fs_info->sb->s_writers.frozen > SB_UNFROZEN ||
+	    freezing(current))
+		return true;
+
+	/* Also check for pending signals. */
+	if (signal_pending(current))
+		return true;
+	return false;
+}
+
 /*
  * Scrub one range which can only has simple mirror based profile.
  * (Including all range in SINGLE/DUP/RAID1/RAID1C*, and each stripe in
@@ -2263,7 +2279,8 @@ static int scrub_simple_mirror(struct scrub_ctx *sctx,
 
 		/* Canceled? */
 		if (atomic_read(&fs_info->scrub_cancel_req) ||
-		    atomic_read(&sctx->cancel_req)) {
+		    atomic_read(&sctx->cancel_req) ||
+		    should_cancel_scrub(fs_info)) {
 			ret = -ECANCELED;
 			break;
 		}
-- 
2.50.1

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

[Askar Safin]

On Thu, Oct 16, 2025 at 2:01 AM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
> I guess the difference is in the systemd's handling of user slice.

As well as I understand, systemd first freezes user slice using
cgroup freezer, then performs kernel suspend (which freezes
everything). I'm not even sure that these two terms "freeze" are
the same thing.

> Anyway, mind to test the attached newer patch?

I tested it.

in-win freeze_filesystems=0 - suspends instantly
in-win freeze_filesystems=1 - suspends instantly
as-a-service freeze_filesystems=0 - suspends instantly
as-a-service freeze_filesystems=1 - suspends instantly

Also, "btrfs scrub" terminates when it gets INT, TERM, HUP or KILL.

Also, system powers off instantly both when scrub is in a window
and when it is run as a service.

Great patch, thank you!

Tested-By: Askar Safin <safinaskar@gmail.com>

-- 
Askar Safin

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

[Qu Wenruo]

在 2025/10/16 19:10, Askar Safin 写道:
> On Thu, Oct 16, 2025 at 2:01 AM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>> I guess the difference is in the systemd's handling of user slice.
> 
> As well as I understand, systemd first freezes user slice using
> cgroup freezer, then performs kernel suspend (which freezes
> everything). I'm not even sure that these two terms "freeze" are
> the same thing.
> 
>> Anyway, mind to test the attached newer patch?
> 
> I tested it.
> 
> in-win freeze_filesystems=0 - suspends instantly
> in-win freeze_filesystems=1 - suspends instantly
> as-a-service freeze_filesystems=0 - suspends instantly
> as-a-service freeze_filesystems=1 - suspends instantly
> 
> Also, "btrfs scrub" terminates when it gets INT, TERM, HUP or KILL.
> 
> Also, system powers off instantly both when scrub is in a window
> and when it is run as a service.
> 
> Great patch, thank you!
> 
> Tested-By: Askar Safin <safinaskar@gmail.com>

Thanks a lot!

Although you may want to add your tested-by tag to the formal patchset here:

https://lore.kernel.org/linux-btrfs/cover.1760607566.git.wqu@suse.com/

So that I can add your tags at merge time.

Thanks,
Qu

>