mirror of
https://github.com/versity/scoutfs.git
synced 2026-02-07 11:10:44 +00:00
045380ca55
Previously we changed item reading to try and read from the start of its locked range instead of from the key that wasn't found in the cache. This greatly improved the performance of access patterns that didn't proceed in key order. We rightly shrank the range of items that we'd claim to cache by the segments that we read. But we missed the case where our search key falls between two segments and we chose to read the next segment instead of the previous. If the previous segment in this case overlapped with the lock range then we were claiming to cache the segments contents but weren't reading it. This would result in bad negative caching of items that existed. scoutfs/500 was tripping over this as it tried to rename a file created by another node. The local renaming node would try to look up a key that only existed in level 0 and not read but negatively cache the items in the previous level 1 segment. We fix this by shrinking the caching range down as we're considering manifest entries instead of up as we process each segment read because we have to shrink based on the segments in the manifest, not the ones we chose to read. With this fixed the rename can see those items in the level 1 segment again. Signed-off-by: Zach Brown <zab@versity.com>