On Tue, Jul 02, 2024 at 12:33:53PM +0000, Trond Myklebust wrote: > On Mon, 2024-07-01 at 10:13 -0400, Mike Snitzer wrote: > > On Mon, Jul 01, 2024 at 09:46:36AM +1000, Dave Chinner wrote: > > > IMO, the only sane way to ensure this sort of nested "back-end page > > > cleaning submits front-end IO filesystem IO" mechanism works is to > > > do something similar to the loop device. You most definitely don't > > > want to be doing buffered IO (double caching is almost always bad) > > > and you want to be doing async direct IO so that the submission > > > thread is not waiting on completion before the next IO is > > > submitted. > > > > Yes, follow-on work is for me to revive the directio path for localio > > that ultimately wasn't pursued (or properly wired up) because it > > creates DIO alignment requirements on NFS client IO: > > https://git.kernel.org/pub/scm/linux/kernel/git/snitzer/linux.git/commit/?h=nfs-localio-for-6.11-testing&id=f6c9f51fca819a8af595a4eb94811c1f90051eab I don't follow - this is page cache writeback. All the write IO from the bdi flusher thread should be page aligned, right? So why does DIO alignment matter here? > > But underlying filesystems (like XFS) have the appropriate checks, we > > just need to fail gracefully and disable NFS localio if the IO is > > misaligned. > > > > Just a reminder to everyone that this is replacing a configuration > which would in any case result in double caching, because without the > localio change, it would end up being a loopback mount through the NFS > server. Sure. That doesn't mean double caching is desirable and it's something we try should avoid if we trying to design a fast server bypass mechanism. -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
