在 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
