Date: Wed, 6 Mar 2019 13:48:39 -0800 From: Conrad Meyer <cem@freebsd.org> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: "bugzilla-noreply@freebsd.org" <bugzilla-noreply@freebsd.org>, "fs@FreeBSD.org" <fs@freebsd.org> Subject: Re: [Bug 235774] [FUSE]: Need to evict invalidated cache contents on fuse_write_directbackend() Message-ID: <CAG6CVpWyMeNBfZqRF7xvw8RAbDtM_iYCWdw0bxvKCOxcWDmP2w@mail.gmail.com> In-Reply-To: <QB1PR01MB35379C69D7EE70F000B1975FDD730@QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM> References: <bug-235774-3630@https.bugs.freebsd.org/bugzilla/> <bug-235774-3630-gv5OeBYwCK@https.bugs.freebsd.org/bugzilla/> <QB1PR01MB35379C69D7EE70F000B1975FDD730@QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Rick, On Wed, Mar 6, 2019 at 1:32 PM Rick Macklem <rmacklem@uoguelph.ca> wrote: > > --- Comment #4 from Conrad Meyer <cem@freebsd.org> --- > >I think fuse's IO_DIRECT path is a mess. Really all IO should go throug= h the > >buffer cache, and B_DIRECT and ~B_CACHE are just flags that control the > >buffer's lifetime once the operation is complete. Removing the "direct" > >backends entirely (except as implementation details of strategy()) would > >simplify and correct the caching logic. > > Hmm, I'm not sure that I agree that all I/O should go through the buffer = cache, > in general. (I won't admit to knowing the fuse code well enough to commen= t > specifically on it.) The scope of the bug and comment you've replied to is just FUSE IO. > =E2=80=A6 having the NFS (or FUSE) client do a > large amount of writing to a file can flood the buffer cache and avoiding= this > for the case where the client won't be reading the file would be nice. > What I am not sure is whether O_DIRECT is a good indicator of "doing a lo= t of > writing that won't be read back". This is the known failure mode of LRU cache policies plus finite cache size plus naive clients. It's not specific to any particular filesystem. You can either enlarge your LRU cache to incorporate the entire working set size, incorporate frequency of access in eviction policy, or have smart clients provide hints (e.g., POSIX_FADV_DONTNEED). O_DIRECT -> IO_DIRECT -> B_DIRECT is already used as a hint in the bufcache to release bufs/pages aggressively. Best, Conrad
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpWyMeNBfZqRF7xvw8RAbDtM_iYCWdw0bxvKCOxcWDmP2w>