On Wed, Sep 20, 2023 at 09:28:44AM -0400, Brian Foster wrote: > 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..
Ah ok - and regardless, this is a new test being enabled. Pulling this patch back in...
