[thirdparty/kernel/linux.git] / Documentation / filesystems / fuse-io.txt

Fuse supports the following I/O modes:

- direct-io
- cached
  + write-through
  + writeback-cache

The direct-io mode can be selected with the FOPEN_DIRECT_IO flag in the
FUSE_OPEN reply.

In direct-io mode the page cache is completely bypassed for reads and writes.
No read-ahead takes place. Shared mmap is disabled.

In cached mode reads may be satisfied from the page cache, and data may be
read-ahead by the kernel to fill the cache.  The cache is always kept consistent
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.

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
uncached, but fully written pages).  No READ requests are ever sent for writes,
so when an uncached page is partially written, the page is discarded.

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