From: Qu Wenruo <wqu@suse.com>
To: dsterba@suse.cz
Cc: linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz
Subject: Re: [PATCH v4 5/6] btrfs: implement shutdown ioctl
Date: Tue, 8 Jul 2025 08:34:09 +0930 [thread overview]
Message-ID: <eac924e4-fb2e-42fd-979a-4a0829f67377@suse.com> (raw)
In-Reply-To: <20250707205125.GI4453@twin.jikos.cz>
在 2025/7/8 06:21, David Sterba 写道:
> On Sun, Jul 06, 2025 at 01:07:19PM +0930, Qu Wenruo wrote:
>> 在 2025/7/5 23:52, David Sterba 写道:
>>>> +static int btrfs_emergency_shutdown(struct btrfs_fs_info *fs_info, u32 flags)
>>>> +{
>>>> + int ret = 0;
>>>> +
>>>> + if (flags >= BTRFS_SHUTDOWN_FLAGS_LAST)
>>>> + return -EINVAL;
>>>> +
>>>> + if (btrfs_is_shutdown(fs_info))
>>>> + return 0;
>>>> +
>>>> + switch (flags) {
>>>> + case BTRFS_SHUTDOWN_FLAGS_LOGFLUSH:
>>>> + case BTRFS_SHUTDOWN_FLAGS_DEFAULT:
>>>> + ret = freeze_super(fs_info->sb, FREEZE_HOLDER_KERNEL, NULL);
>>>
>>> Recently I've looked at scrub blocking filesystem freezing and it does
>>> not work because it blocks on the semaphore taken in mnt_want_write,
>>> also taken in freeze_super().
>>>
>>> I have an idea for fix, basically pause scrub, undo mnt_want_write
>>> and then call freeze_super. So we'll need that too for shutdown. Once
>>> implemented the fixup would be to use btrfs_freeze_super callback here.
>>
>> It may not be that simple.
>>
>> freeze_super() itself is doing extra works related to the
>> stage/freeze_owner/etc.
>>
>> I'm not sure if it's a good idea to completely skip that part.
>>
>> I'd prefer scrub to check the frozen stage, and if it's already in any
>> FREEZE stages, exit early.
>
> I have working prototype for pausing scrub that does not need to exit,
> so far I've tested it with fsfreeze in a VM, I still need to test actual
> freezing for suspend purposes.
Not sure how would you test with running scrub and freeze, but please
enable lockdep for the potential reversed lock sequence related to btrfs
specific locks and s_umount/s_writers.rw_sem.
But I guess we should have a test case utilizing freeze and scrub.
Especially that fsstress doesn't include freeze, thus we have to
manually do scrub and freeze (maybe with fsstress at the background).
We need such test case no matter if we allow scrub to be paused/canceled.
Thanks,
Qu
next prev parent reply other threads:[~2025-07-07 23:04 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-04 0:42 [PATCH v4 0/6] btrfs: add remove_bdev() callback Qu Wenruo
2025-07-04 0:42 ` [PATCH v4 1/6] fs: enhance and rename shutdown() callback to remove_bdev() Qu Wenruo
2025-07-04 9:00 ` (subset) " Christian Brauner
2025-07-04 9:05 ` Jan Kara
2025-07-07 23:02 ` Dave Chinner
2025-07-07 23:22 ` Qu Wenruo
2025-07-08 0:45 ` Darrick J. Wong
2025-07-08 2:09 ` Qu Wenruo
2025-07-08 3:06 ` Qu Wenruo
2025-07-08 5:05 ` Dave Chinner
2025-07-08 5:41 ` Qu Wenruo
2025-07-08 7:55 ` Christian Brauner
2025-07-08 22:59 ` Dave Chinner
2025-07-08 23:07 ` Qu Wenruo
2025-07-09 0:35 ` Kent Overstreet
2025-07-09 0:55 ` Qu Wenruo
2025-07-09 1:13 ` Kent Overstreet
2025-07-10 8:33 ` Christian Brauner
2025-07-10 10:54 ` Christoph Hellwig
2025-07-08 10:20 ` Jan Kara
2025-07-08 20:20 ` Darrick J. Wong
2025-07-08 22:12 ` Qu Wenruo
2025-07-10 8:40 ` Christian Brauner
2025-07-10 9:54 ` Qu Wenruo
2025-07-11 9:34 ` Christian Brauner
2025-07-10 10:52 ` Christoph Hellwig
2025-07-04 0:42 ` [PATCH v4 2/6] btrfs: introduce a new fs state, EMERGENCY_SHUTDOWN Qu Wenruo
2025-07-04 0:42 ` [PATCH v4 3/6] btrfs: reject file operations if in shutdown state Qu Wenruo
2025-07-05 14:10 ` David Sterba
2025-07-04 0:42 ` [PATCH v4 4/6] btrfs: reject delalloc ranges " Qu Wenruo
2025-07-04 0:42 ` [PATCH v4 5/6] btrfs: implement shutdown ioctl Qu Wenruo
2025-07-05 14:22 ` David Sterba
2025-07-06 3:37 ` Qu Wenruo
2025-07-07 20:51 ` David Sterba
2025-07-07 23:04 ` Qu Wenruo [this message]
2025-07-08 0:53 ` David Sterba
2025-07-04 0:42 ` [PATCH v4 6/6] btrfs: implement remove_bdev super operation callback 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=eac924e4-fb2e-42fd-979a-4a0829f67377@suse.com \
--to=wqu@suse.com \
--cc=brauner@kernel.org \
--cc=dsterba@suse.cz \
--cc=jack@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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