mirror of
https://github.com/versity/scoutfs.git
synced 2026-02-07 19:20:44 +00:00
829126790b
We don't have strict consistency protocols protecting the "physical" caches that hold btree blocks and segments. We have metadata that tells a reader that it's hit a stale cached entry and needs to invalidate and read a the current version from the media. This implements the retrying. If we get stale sequence numbers in segments or btree blocks we invalidate them from the cache and return -ESTALE. This can only happen when reading structures that could have been modified remotely. This means btree reads in the clients and segment reads for everyone. btree reads on the server are always consistent because it is the only writer. Adding retrying to item reading and compaction catches all of these cases. Stale reads are triggered by inconsistency. But that could also be persistent corruption in persistent media. Callers need to be careful to turn their retries into hard errors if they're persistent. Item reading can do this because it knows the btree root seq that anchored the walk. Compaction doesn't do this today. That gets addressed in a big sweep of error handling at some point in the not too distant future. Signed-off-by: Zach Brown <zab@versity.com>