On 11/12/24 12:39 PM, Brian Foster wrote: > On Tue, Nov 12, 2024 at 12:08:45PM -0700, Jens Axboe wrote: >> On 11/12/24 11:44 AM, Brian Foster wrote: >>> On Tue, Nov 12, 2024 at 10:19:02AM -0700, Jens Axboe wrote: >>>> On 11/12/24 10:06 AM, Jens Axboe wrote: >>>>> On 11/12/24 9:39 AM, Brian Foster wrote: >>>>>> On Tue, Nov 12, 2024 at 08:14:28AM -0700, Jens Axboe wrote: >>>>>>> On 11/11/24 10:13 PM, Christoph Hellwig wrote: >>>>>>>> On Mon, Nov 11, 2024 at 04:42:25PM -0700, Jens Axboe wrote: >>>>>>>>> Here's the slightly cleaned up version, this is the one I ran testing >>>>>>>>> with. >>>>>>>> >>>>>>>> Looks reasonable to me, but you probably get better reviews on the >>>>>>>> fstests lists. >>>>>>> >>>>>>> I'll send it out once this patchset is a bit closer to integration, >>>>>>> there's the usual chicken and egg situation with it. For now, it's quite >>>>>>> handy for my testing, found a few issues with this version. So thanks >>>>>>> for the suggestion, sure beats writing more of your own test cases :-) >>>>>>> >>>>>> >>>>>> fsx support is probably a good idea as well. It's similar in idea to >>>>>> fsstress, but bashes the same file with mixed operations and includes >>>>>> data integrity validation checks as well. It's pretty useful for >>>>>> uncovering subtle corner case issues or bad interactions.. >>>>> >>>>> Indeed, I did that too. Re-running xfstests right now with that too. >>>> >>>> Here's what I'm running right now, fwiw. It adds RWF_UNCACHED support >>>> for both the sync read/write and io_uring paths. >>>> >>> >>> Nice, thanks. Looks reasonable to me at first glance. A few randomish >>> comments inlined below. >>> >>> 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" ;-) > Random other thought: I also wonder if uncached I/O should be an > exclusive mode more similar to like how O_DIRECT or AIO is implemented. > But I dunno, maybe it doesn't matter that much (or maybe others will > have opinions on the fstests list). Should probably exclude it with DIO, as it should not do anything there anyway. Eg if you ask for DIO, it gets turned off. For some of the other exclusions, they seem kind of wonky to me. Why can you use libaio and io_uring at the same time, for example? io_uring will work just fine with both buffered and direct IO, and it'll do the right thing with uncached as well. AIO is really a DIO only thing, not useful for anything else. -- Jens Axboe
