Re: [PATCH 5/5] docs: fuse: improve FUSE consistency explanation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 2023/7/11 12:42, Randy Dunlap wrote:
Hi--

On 7/10/23 21:34, Jiachen Zhang wrote:
Signed-off-by: Jiachen Zhang <zhangjiachen.jaycee@xxxxxxxxxxxxx>
---
  Documentation/filesystems/fuse-io.rst | 32 +++++++++++++++++++++++++--
  1 file changed, 30 insertions(+), 2 deletions(-)

diff --git a/Documentation/filesystems/fuse-io.rst b/Documentation/filesystems/fuse-io.rst
index 255a368fe534..cdd292dd2e9c 100644
--- a/Documentation/filesystems/fuse-io.rst
+++ b/Documentation/filesystems/fuse-io.rst

@@ -24,7 +31,8 @@ after any writes to the file.  All mmap modes are supported.
  The cached mode has two sub modes controlling how writes are handled.  The
  write-through mode is the default and is supported on all kernels.  The
  writeback-cache mode may be selected by the FUSE_WRITEBACK_CACHE flag in the
-FUSE_INIT reply.
+FUSE_INIT reply. In either modes, if the FOPEN_KEEP_CACHE flag is not set in

                        either mode,

+the FUSE_OPEN, cached pages of the file will be invalidated immediatedly.

                                                                immediately.

In write-through mode each write is immediately sent to userspace as one or more
  WRITE requests, as well as updating any cached pages (and caching previously
@@ -38,7 +46,27 @@ reclaim on memory pressure) or explicitly (invoked by close(2), fsync(2) and
  when the last ref to the file is being released on munmap(2)).  This mode
  assumes that all changes to the filesystem go through the FUSE kernel module
  (size and atime/ctime/mtime attributes are kept up-to-date by the kernel), so
-it's generally not suitable for network filesystems.  If a partial page is
+it's generally not suitable for network filesystems (you can consider the
+writeback-cache-v2 mode mentioned latter for them).  If a partial page is

                                      later

  written, then the page needs to be first read from userspace.  This means, that
  even for files opened for O_WRONLY it is possible that READ requests will be
  generated by the kernel.




Thanks, Randy. I will fix them in the next version.

Jiachen



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux