Re: Freezing (was: Re: fstests generic/441 -- occasional bcachefs failure)

[Dave Chinner <dchinner@redhat.com>]

On Fri, Feb 03, 2023 at 07:35:15PM -0500, Kent Overstreet wrote:
> On Fri, Feb 03, 2023 at 11:51:12AM +1100, Dave Chinner wrote:
> > What do you need to know? The vast majority of the freeze
> > infrastructure is generic and the filesystem doesn't need to do
> > anything special. The only thing it needs to implement is
> > ->freeze_fs to essentially quiesce the filesystem - by this stage
> > all the data has been written back and all user-driven operations
> > have either been stalled or drained at either the VFS or transaction
> > reservation points.
> > 
> > This requires the filesystem transaction start point to call
> > sb_start_intwrite() in a location the transaction start can block
> > safely forever, and to call sb_end_intwrite() when the transaction
> > is complete and being torn down. 
> > 
> > [Note that bcachefs might also require
> > sb_{start/end}_{write/pagefault} calls in paths that it has custom
> > handlers for and to protect against ioctl operations triggering
> > modifications during freezes.]
> > 
> > This allows freeze_super() to set a barrier to prevent new
> > transactions from starting, and to wait on transactions in flight to
> > drain. Once all transactions have drained, it will then call
> > ->freeze_fs if it is defined so the filesystem can flush it's
> > journal and dirty in-memory metadata so that it becomes consistent
> > on disk without requiring journal recovery to be run.
> > 
> > This basically means that once ->fs_freeze completes, the filesystem
> > should be in the same state on-disk as if it were unmounted cleanly,
> > and the fs will not issue any more IO until the filesystem is
> > thawed. Thaw will call ->unfreeze_fs if defined before unblocking
> > tasks so that the filesystem can restart things that may be needed
> > for normal operation that were stopped during the freeze.
> > 
> > It's not all that complex anymore - a few hooks to enable
> > modification barriers to be placed and running the
> > writeback part of unmount in ->freeze_fs is the main component
> > of the work that needs to be done....
> 
> Thanks, that is a lot simpler than I was thinking - I guess I was
> thinking about task freezing for suspend, that definitely had some
> tricky bits.

"freezing for suspend" is a mess - it should just be calling
freeze_super() and letting the filesystem take care of everything to
do with freezing the filesystem. The whole idea that we can suspend
a filesystem safely by running sync() and stopping kernel threads and
workqueues from running is .... broken.

> Sounds like treating it as if we were remounting read-only
> is all we need to do.

Yup, pretty much. XFS shares all the log quiescing code between
->freeze_fs and remount_ro. The only difference is that remount_ro
has to do all the work to write dirty data back to disk before
it quiesces the log....

Cheers,

Dave.
-- 
Dave Chinner
dchinner@redhat.com