Date: Wed, 06 Mar 2019 17:18:33 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 235774] [FUSE]: Need to evict invalidated cache contents on fuse_write_directbackend() Message-ID: <bug-235774-3630-gv5OeBYwCK@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-235774-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-235774-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235774 --- Comment #4 from Conrad Meyer <cem@freebsd.org> --- I think fuse's IO_DIRECT path is a mess. Really all IO should go through t= he 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. Looking at UFS; it really only has a non-bufcache "rawread" path that uses pbufs (and flushes all dirty bufs on the vnode first!). There is no equiva= lent for O_DIRECT writes. And ffs_rawread basically duplicates the ordinary read path for extremely limited cases (single iov, must be sector sized/aligned, etc) =E2=80=94 it's unclear to me why it exists. ffs_write() just uses the ordinary buf cache, paying attention to ioflag & IO_DIRECT and using vfs_bio_set_flags(, ioflag) to propagate it to b_flags & B_DIRECT. (B_DIRECT causes the buffer to be released immediately when it is freed, instead of being cached.) I think we should probably learn from UFS for FUSE's IO modes: 1. Keep and enable the direct_io option, for users who truly want to bypass= the buf cache entirely. Preferably this is a per-mountpoint option rather than= a global, but that is an orthogonal enhancement. Confusingly, this is distin= ct from opening a file O_DIRECT. Maybe the sysctl/option can be renamed. "raw io?" 2. Do not actually use the "direct" paths in FUSE outside of global direct_= io mode (or a future MP-specific always-direct mode). 3. A caveat here is: FUSE filesystems (?)don't have a native sector/block s= ize, but the buf cache is in block units. And, we translate O_WRONLY opens into FUSE FUFH_WRONLY opens. So there will be some trickiness in partial block writes with a O_WRONLY handle when the block is not in cache. Today that is sidestepped by invoking direct mode, but shouldn't be. Anyway, this is all future cleanup ideas for this area. For the more limit= ed scope of fixing just this PR, we can probably draw inspiration from ffs_rawread_sync(). --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-235774-3630-gv5OeBYwCK>