Re: [PATCH v2 4/4] bcachefs: initial freeze/unfreeze support

[Brian Foster <bfoster@redhat.com>]

On Tue, Sep 19, 2023 at 09:21:16PM -0400, Kent Overstreet wrote:
> Pulled this into the testing branch and then got
> 
> https://evilpiepirate.org/~testdashboard/c/de4ea1e2a9ceec5d55fffbc1acab89f0dc8f90b6/xfstests.generic.459/log.br
> 
> So I'll likely kick this patch back out for now, let me know when you
> have a fixed version :)
> 

Ah, sorry.. I should have mentioned this in the cover letter. I'm aware
of this failure but my initial triage has it as an unrelated problem.
That test basically induces I/O errors by explicitly overprovisioning a
dm-thin volume for the fs. The original bug was a livelock issue on XFS
related to metadata writeback failure/retry in this particular scenario.

The test relies on freeze in that it basically consumes all of the
initially provisioned space, issues a freeze in the background (which
will start off hanging because not everything can write back until more
storage is available), and then grows available space so freeze can
proceed to completion. It uses the success/failure of the freeze to
determine pass/failure, and if the freeze fails it looks like it expects
the filesystem to have been remounted ro (which I believe is ext4's way
of dealing with this).

My notes say that freeze failed because the fs shutdown, which I think
is due to the whole overprovision/flush thing leading to I/O errors
(i.e. expected behavior, probably similar to ext4). But TBH I hadn't dug
into it further than initial triage to rule out the core freeze
mechanism itself. I'll dig more into that soon to see whether we need to
change the test or something in the kernel, though I don't think it
necessarily needs to gate freeze support..

Brian