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
