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. |