On 11/12/24 1:25 PM, Jens Axboe wrote: >>>>>> BTW, I should have also mentioned that fsx is also useful for longer >>>>>> soak testing. I.e., fstests will provide a decent amount of coverage as >>>>>> is via the various preexisting tests, but I'll occasionally run fsx >>>>>> directly and let it run overnight or something to get the op count at >>>>>> least up in the 100 millions or so to have a little more confidence >>>>>> there isn't some rare/subtle bug lurking. That might be helpful with >>>>>> something like this. JFYI. >>>>> >>>>> Good suggestion, I can leave it running overnight here as well. Since >>>>> I'm not super familiar with it, what would be a good set of parameters >>>>> to run it with? >>>>> >>>> >>>> Most things are on by default, so I'd probably just go with that. -p is >>>> useful to get occasional status output on how many operations have >>>> completed and you could consider increasing the max file size with -l, >>>> but usually I don't use more than a few MB or so if I increase it at >>>> all. >>> >>> When you say default, I'd run it without arguments. And then it does >>> nothing :-) >>> >>> Not an fs guy, I never run fsx. I run xfstests if I make changes that >>> may impact the page cache, writeback, or file systems. >>> >>> IOW, consider this a "I'm asking my mom to run fsx, I need to be pretty >>> specific" ;-) >>> >> >> Heh. In that case I'd just run something like this: >> >> fsx -p 100000 <file> >> >> ... and see how long it survives. It may not necessarily be an uncached >> I/O problem if it fails, but depending on how reproducible a failure is, >> that's where a cli knob comes in handy. > > OK good, will give that a spin. Ran overnight, no issues seen. Just terminated the process. For funsies, I also added RWF_UNCACHED support to qemu and had the vm booted with that as well, to get some host side testing too. Everything looks fine. This is running: https://git.kernel.dk/cgit/linux/log/?h=buffered-uncached.7 which is the current branch. -- Jens Axboe
