Documentation/filesystems/fuse-io.rst

   1 .. SPDX-License-Identifier: GPL-2.0
   2
   3 ==============
   4 Fuse I/O Modes
   5 ==============
   6
   7 Fuse supports the following I/O modes:
   8
   9 - direct-io
  10 - cached
  11   + write-through
  12   + writeback-cache
  13
  14 The direct-io mode can be selected with the FOPEN_DIRECT_IO flag in the
  15 FUSE_OPEN reply.
  16
  17 In direct-io mode the page cache is completely bypassed for reads and writes.
  18 No read-ahead takes place. Shared mmap is disabled by default. To allow shared
  19 mmap, the FUSE_DIRECT_IO_ALLOW_MMAP flag may be enabled in the FUSE_INIT reply.
  20
  21 In cached mode reads may be satisfied from the page cache, and data may be
  22 read-ahead by the kernel to fill the cache.  The cache is always kept consistent
  23 after any writes to the file.  All mmap modes are supported.
  24
  25 The cached mode has two sub modes controlling how writes are handled.  The
  26 write-through mode is the default and is supported on all kernels.  The
  27 writeback-cache mode may be selected by the FUSE_WRITEBACK_CACHE flag in the
  28 FUSE_INIT reply.
  29
  30 In write-through mode each write is immediately sent to userspace as one or more
  31 WRITE requests, as well as updating any cached pages (and caching previously
  32 uncached, but fully written pages).  No READ requests are ever sent for writes,
  33 so when an uncached page is partially written, the page is discarded.
  34
  35 In writeback-cache mode (enabled by the FUSE_WRITEBACK_CACHE flag) writes go to
  36 the cache only, which means that the write(2) syscall can often complete very
  37 fast.  Dirty pages are written back implicitly (background writeback or page
  38 reclaim on memory pressure) or explicitly (invoked by close(2), fsync(2) and
  39 when the last ref to the file is being released on munmap(2)).  This mode
  40 assumes that all changes to the filesystem go through the FUSE kernel module
  41 (size and atime/ctime/mtime attributes are kept up-to-date by the kernel), so
  42 it's generally not suitable for network filesystems.  If a partial page is
  43 written, then the page needs to be first read from userspace.  This means, that
  44 even for files opened for O_WRONLY it is possible that READ requests will be
  45 generated by the kernel.