On Wed, 2017-11-29 at 15:23 -0800, Luis R. Rodriguez wrote:
> This is a followup from the original RFC which proposed to start
> to kill kthread freezing all together [0]. Instead of going straight
> out to the jugular for kthread freezing this series only addresses
> killing freezer calls on filesystems which implement freeze_fs, after
> we let the kernel freeze these filesystems for us on suspend.
>
> This approach puts on a slow but steady path towards the original goal
> though. Each subsystem could look for similar solutions. Even with
> filesystems we're not all done yet, after this we'll still have to
> decide what to do about filesystems which do not implement freeze_fs().
>
> Motivation and problem:
>
> kthreads have some semantics for freezing, which helps the kernel
> freeze them when a system is going to suspend or hibernation. These
> semantics are not well defined though, and it actually turns out
> pretty hard to get it right.
>
> Without a proper solution suspend and hibernation are fragile on filesystems,
> it can easily break suspend and fixing such issues are in no way trivial [1]
> [2].
>
> Proposed solution:
>
> Instead of fixing such semantics and trying to get all filesystems to do it
> right, we can easily do away with all freezing calls if the filesystem
> implements a proper freeze_fs() callback. The following 9 filesystems have
> freeze_fs() implemented as such we can let the kernel issue the callback upon
> suspend and thaw on resume automatically on our behalf.
>
> o xfs
> o reiserfs
> o nilfs2
> o jfs
> o f2fs
> o ext4
> o ext2
> o btrfs
>
> Of these, the following have freezer helpers, which can then be removed
> after the kernel automaticaly calls freeze_fs for us on suspend:
>
> o xfs
> o nilfs2
> o jfs
> o f2fs
> o ext4
>
> I've tested this on a system with ext4 and XFS, and have let 0-day go at
> without issues. I have branches availabe for linux-next [3] and Linus'
> latest tree [4].
>
> Further testing, thoughts, reviews, flames are all equally appreciated.
Hello Luis,
It's great to see that you are making progress with this work :-) However,
what's not clear to me is what your (long-term) plan is for freezing
filesystems that e.g. exist on top of a md RAID1 block device? The md resync
thread must be stopped before a system is frozen. Today the md driver uses
the kthread freezing mechanism for that purpose. Do you have a plan for
handling the more complicated scenarios, e.g. a filesystem that exists on top
of an md device where the md device uses one or more files as backing store
and with the loop driver between the md device and the files?
How about filesystems implemented in user space using the FUSE driver?
Patch 6/11 of this series freezes user space processes before freezing
filesystems. Will that work for FUSE filesystems?
Thanks,
Bart.��.n��������+%������w��{.n�����{����� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
