On Fri, Feb 10, 2023 at 04:44:41AM +0000, Matthew Wilcox wrote: > On Fri, Feb 10, 2023 at 03:06:26PM +1100, Dave Chinner wrote: > > So while I was pondering the complexity of this and watching a great > > big shiny rocket create lots of heat, light and noise, it occurred > > That was kind of fun :) > > to me that we already have a mechanism for preventing page cache > > data from being changed while the folios are under IO: > > SB_I_STABLE_WRITES and folio_wait_stable(). > > I thought about bringing that up, but it's not quite right. That works > great for writeback, but it only works for writeback. We'd need to track > another per-folio counter ... it'd be like the page pinning kerfuffle, > only worse. Hmmm - I didn't think of that. It needs the counter because the "stable request" is per folio reference state, not per folio state, right? And the single flag works for writeback because we can only have one writeback context in progress at a time? Yeah, not sure how to deal with that easily. > And for such a rare thing it seems like a poor use of 32 > bits of per-page state. Maybe, but zero copy file data -> network send is a pretty common workload. Web servers, file servers, remote backup programs, etc. Having files being written whilst others are reading them is not as common, but that does happen in a wide variety of shared file server environments. Regardless, I just had a couple of ideas - it they don't work so be it. > Not to mention that you can effectively block > all writes to a file for an indefinite time by splicing pages to a pipe > that you then never read from. No, I wasn't suggesting that we make pages in transit stable - they only need to be stable while the network stack requires them to be stable.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
