Optionally disable FUSE_CAP_ASYNC_READ #395
Comments
hanwen
pushed a commit
that referenced
this issue
Aug 2, 2021
We enable FUSE_CAP_ASYNC_READ per default, which means that the kernel can (and does) submit multiple concurrent out-of-order read requests to service userspace reads and kernel readahead. For some backing storages, like Amazon Cloud Drive, out-of-order reads are expensive. gocryptfs has implemented a delay-based workaround with its `-serialize_reads` flag for this case (see rfjakob/gocryptfs#92 for details). Not enabling FUSE_CAP_ASYNC_READ makes the kernel do this for us, as verified by adding debug output to gocryptfs, so expose it as a mount flag in MountOptions. Fixes: #140 Graphs-at: #395 Related: rfjakob/gocryptfs#92 Change-Id: I10f947d71e1453989c4a9b66fbb0407f7163994f
|
Merged |
rfjakob
added a commit
to rfjakob/gocryptfs
that referenced
this issue
Aug 30, 2021
Will be replaced by go-fuse's new SyncRead flag. More info: hanwen/go-fuse#395 SyncRead commit: hanwen/go-fuse@15a8bb0
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For some backing storages (cloud drives), out-of-order and concurrent reads are expensive.
Give the caller the option to disable FUSE_CAP_ASYNC_READ so reads are in-order.
Patch is on gerrithub ( https://review.gerrithub.io/c/hanwen/go-fuse/+/516150 ), this ticket exists so I can show some graphs.
Reading a 10MB file off a gocryptfs per default looks like this:
Removing FUSE_CAP_ASYNC_READ, it looks like this:
Spreadsheet attached for future reference here: SyncRead.ods
Read speed is 1GB/s in default mode, and 500MB/s with FUSE_CAP_ASYNC_READ disabled. The currently implemented delay-based workaround in gocryptfs (the
-serialize_readsflag), get 97MB/s.Exposing the option to disable FUSE_CAP_ASYNC_READ will allow gocryptfs to drop the delay-based workaround and get much better performance.
The text was updated successfully, but these errors were encountered: