cachepc-linux

Fork of AMDESE/linux with modifications for CachePC side-channel attack
git clone https://git.sinitax.com/sinitax/cachepc-linux
Log | Files | Refs | README | LICENSE | sfeed.txt

fuse-io.rst (1971B)


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