Re: [PATCH v2] xfs: enable WQ_MEM_RECLAIM on m_sync_workqueue

[Trond Myklebust <trondmy@hammerspace.com>]

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
> 
> 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.

Use of O_DIRECT to xfs would impose alignment requirements by the lower
filesystem that are not being followed by the upper filesystem. A
"remedy" where we fall back to disabling localio if there is no
alignment won't fix anything. You will now have added the extra nfsd
layer back in, and so have the extra networking overhead in addition to
the memory management problems you were trying to solve with O_DIRECT.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com