Add DAS FS fallback to old layout, fix health check #2510
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR
by-expiry-timestamp
entries.As of release 3.1.0, the DAS filesystem layout automatically migrates to the new trie based layout if the migration is detected to not have occurred yet, based on the absence of the
by-data-hash
andby-expiry-timestamp
directories. If an operator rolls back to an older version, some more batch data is written with the old layout, and then rolls forward again, only the new layout data will be detected. This PR makes theGetByHash
method also try to get the data using the old layout to handle these cases gracefully.The issue of the health check creating too many
by-expiry-timestamp
entries is also fixed. The/health
REST endpoint andHealthCheck
JSON-RPC method for the RPC server when used with the local file store do a full end to end test of the storage backend by writing some data and reading it back. It always writes the same data to save on storage space, but previously it wrote a different expiry time each time. This cause theby-expiry-timestamp
index to be spammed with entries for this same data and eventually to fail with "too many links"Testing done
Backwards compat
Set up a data directory with some data in new layout and some in old layout.
Check that the data from both layouts is fetchable.
Check data that doesn't exist (last byte of hash changed) is� still handled correctly
Health check fix
Used the
/health
endpoint several times to create the test data.Test that it is pruned on startup along with other files needing pruning if pruning is enabled. Then create it again and check it is pruned on next pruning iteration.