Allow seeking backwards within a prefetch stream

Linux asynchronous readahead confuses our prefetcher by sometimes making the stream appear to go backwards, even though the customer is actually just reading sequentially (awslabs#488). The problem is that with parallel FUSE threads, the two asynchronous read operations can arrive to the prefetcher out of order. This change allows us to tolerate a little bit of backwards seeking in a prefetch stream. We keep around a little bit of previously read data and can reload it in the event that a seek goes backwards. We do this by creating a fake new request containing the rewound bytes, so that the existing read logic will pick them up. I chose an arbitrary max for the backwards seek buffer, big enough to handle Linux readahead. This should fix the readahead issue: in my testing, I no longer saw slow sequential reads, and the logs confirmed this seeking logic was being triggered in both directions (forwards and backwards), consistent with the readahead requests sometimes arriving out of order. Signed-off-by: James Bornholt <[email protected]>
jamesbornholt · Oct 16, 2023 · ae10a21 · ae10a21
1 parent 39823c5
commit ae10a21
Show file tree

Hide file tree

Showing 5 changed files with 322 additions and 83 deletions.
diff --git a/mountpoint-s3/CHANGELOG.md b/mountpoint-s3/CHANGELOG.md
@@ -1,5 +1,11 @@
 ## Unreleased
 
+### Breaking changes
+* ...
+
+### Other changes
+* Fixed a bug that cause poor performance for sequential reads in some cases ([#488](https://github.com/awslabs/mountpoint-s3/pull/488)). A workaround we have previously shared for this issue (setting the `--max-threads` argument to `1`) is no longer necessary with this fix. ([#556](https://github.com/awslabs/mountpoint-s3/pull/556))
+
 ## v1.0.2 (September 22, 2023)
 
 ### Breaking changes