Bug #9363
Updated by Tom Clegg almost 5 years ago
The following sequence can break the invariant Keep relies on for safe garbage collection[1]:
# Write data blocks
# Save collection
# Wait for original blob signature TTLs (from step 1) to expire
# Retrieve the collection (setting aside a copy in memory)
# Update the collection to remove references to some (or all) blocks
# Wait for keep-balance to do a garbage-collection sweep
# Update the collection (or save a new one) using the blocks/signatures set aside in step 4
If the only reference to a block is the one in this collection, the block may be deleted during step 6, resulting in a collection being saved successfully in step 7 even though some of its data is missing.
Proposed solution:
When updating a collection, detect block references that are being dropped[2]; if there are any, save a temporary collection (trashed, readable only by admin) referencing all of the dropped blocks. These will be cleaned up when they expire, and in the meantime they will be seen by keep-balance, thus protecting them until even their new signatures (issued in step 4) expire.
fn1. If any client has a signed block locator with a future timestamp, that block either [i] is newer than BlobSignatureTTL according to the timestamp stored on the backend, and therefore won't be deleted; or [ii] appears in a collection record where keep-balance can see it, and therefore won't be deleted.
fn2. This might be done during the (existing) @strip_signatures_and_update_replication_confirmed@ hook where we detect whether references to new blocks have been added, so we know whether to reset the @replication_confirmed@ columns.