- 05 Aug, 2015 1 commit
-
-
Aaron Jacobs authored
Allowing the kernel to send multiple reads for the same file handle concurrently interferes with sequential read detection like that in GoogleCloudPlatform/gcsfuse#103.
-
- 04 Aug, 2015 4 commits
-
-
Aaron Jacobs authored
One of them caused the writeMessage error observed on OS X in GoogleCloudPlatform/gcsfuse#101.
-
Aaron Jacobs authored
It's not expecting them.
-
Aaron Jacobs authored
-
Aaron Jacobs authored
-
- 03 Aug, 2015 16 commits
-
-
Aaron Jacobs authored
This reproduces the writeMessage errors from GoogleCloudPlatform/gcsfuse#101.
-
Aaron Jacobs authored
-
Aaron Jacobs authored
-
Aaron Jacobs authored
-
Aaron Jacobs authored
-
Aaron Jacobs authored
-
Aaron Jacobs authored
-
Aaron Jacobs authored
-
Aaron Jacobs authored
-
Aaron Jacobs authored
-
Aaron Jacobs authored
-
Aaron Jacobs authored
-
Aaron Jacobs authored
-
Aaron Jacobs authored
-
Aaron Jacobs authored
-
Aaron Jacobs authored
For GoogleCloudPlatform/gcsfuse#99.
-
- 29 Jul, 2015 19 commits
-
-
Aaron Jacobs authored
-
Aaron Jacobs authored
-
Aaron Jacobs authored
-
Aaron Jacobs authored
-
Aaron Jacobs authored
-
Aaron Jacobs authored
-
Aaron Jacobs authored
-
Aaron Jacobs authored
-
Aaron Jacobs authored
-
Aaron Jacobs authored
-
Aaron Jacobs authored
-
Aaron Jacobs authored
-
Aaron Jacobs authored
-
Aaron Jacobs authored
On Linux this significantly increases gcsfuse sequential read throughput.
-
Aaron Jacobs authored
-
Aaron Jacobs authored
-
Aaron Jacobs authored
-
Aaron Jacobs authored
As best I can tell, this instructs the kernel not to synchronize on the completion of a read request before sending further requests. This definitely means further read requests, but I believe it means any sort of request as well. It appears to make a big difference to gcsfuse read support.
-
Aaron Jacobs authored
-