未验证 提交 e674a4b1 编写于 作者: C Changjian Gao 提交者: GitHub

Docs: Add "Metadata Cache in Client" (#541)

* Docs: Add "Metadata Cache in Client"

* Update

* Update
上级 e9bf52af
......@@ -311,7 +311,7 @@ func clientFlags() []cli.Flag {
&cli.Float64Flag{
Name: "open-cache",
Value: 0.0,
Usage: "open files cache timeout in seconds",
Usage: "open files cache timeout in seconds (0 means disable this feature)",
},
&cli.StringFlag{
Name: "subdir",
......
......@@ -4,7 +4,7 @@ To improve the performance, JuiceFS supports caching in multiple levels to reduc
## Metadata Cache
JuiceFS caches metadata in the kernel to improve the performance.
JuiceFS caches metadata in the kernel and client (i.e. JuiceFS process) to improve the performance.
### Metadata Cache in Kernel
......@@ -18,9 +18,19 @@ Three kinds of metadata can be cached in kernel: attribute, entry (file) and dir
Attribute, entry and direntry are cached for 1 second by default, to speedup lookup and getattr operations.
### Metadata Cache in Client
> **Note**: This feature requires JuiceFS >= 0.15.0.
Attributes are cached in client automatically when `open()` a file. If [`--open-cache`](command_reference.md#juicefs-mount) option is set (value should greater than 0) and when the cache timeout hasn't reached, `getattr()` and `open()` call will return immediately.
Chunks and slices information are cached in client automatically when `read()` a file (refer to [here](how_juicefs_store_files.md) to learn what are chunk and slice). When `read()` same file and same chunk again, slices will be returned immediately.
All metadata cache of one file will be removed in the background automatically when this file hasn't been opened by any process in a period of time (default is 1 hour).
### Consistency
If only one client is connected, the cached metadata will be invalidated automatically upon modification. No impact on consistency.
JuiceFS provides close-to-open consistency. It means once a file is closed, the following open and read are guaranteed see the data written before close, either in same host or different host. Particularly, within same mount point, read can see all data written before it immediately (no need to reopen the file).
In case multiple clients, the only way to invalidate metadata cache in the kernel is waiting for timeout.
......@@ -32,7 +42,7 @@ Data cache is also provided in JuiceFS to improve performance, including page ca
### Data Cache in Kernel
Kernel will cache content of recently visited files automatically. When the file is reopened, the content can be fetched from kernel cache directly for best performance.
Kernel will cache content of recently visited files automatically. When the file is reopened and its modification time (mtime) hasn't changed, the content can be fetched from kernel cache directly for best performance.
Reading the same file in JuiceFS repeatedly will be extremely fast, with milliseconds latency and gigabytes throughput.
......
......@@ -176,9 +176,6 @@ file entry cache timeout in seconds (default: 1)
`--dir-entry-cache value`\
dir entry cache timeout in seconds (default: 1)
`--open-cache value`\
open file cache timeout in seconds (default: 0)
`--enable-xattr`\
enable extended attributes (xattr) (default: false)
......@@ -221,6 +218,9 @@ min free space (ratio) (default: 0.1)
`--cache-partial-only`\
cache only random/small read (default: false)
`--open-cache value`\
open file cache timeout in seconds (0 means disable this feature) (default: 0)
### juicefs umount
#### Description
......@@ -285,6 +285,9 @@ min free space (ratio) (default: 0.1)
`--cache-partial-only`\
cache only random/small read (default: false)
`--open-cache value`\
open file cache timeout in seconds (0 means disable this feature) (default: 0)
`--access-log value`\
path for JuiceFS access log
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册