mirror of
https://github.com/versity/scoutfs.git
synced 2026-05-01 18:35:43 +00:00
f5577e26b1
The forest reader reads items from the fs_root and all log btrees and gives them to the caller who tracks them to resolve version differences. The reads can run into stale blocks which have been overwritten. The forest reader was implementing the retry under the item state in the caller. This can corrupt items that are only seen firest in an old fs root before a merge and then only seen in the fs_root after a merge. In this case the item won't have any versioning and the existing version from the old fs_root is preferred. This is particularly bad when the new version was deleted -- in that case we have no metadata which would tell us to drop the old item that was read from the old fs_root. This is fixed by pushing the retry up to callers who wipe the item state before each retry. Now each set of items is related to a single snapshot of the fs_root and logs at one point in time. I haven't seen definitive evidence of this happening in practice. I found this problem after putting on my craziest thinking toque and auditing the code for places where we could lose item updates. Signed-off-by: Zach Brown <zab@versity.com>