Feature #9364

Updated by Tom Clegg about 4 years ago

See [[Expedited delete]] Example use case: a user has stored a very large collection, then realized one or more of the following:
* This data should not be stored here at all (uploaded the wrong files)
* This data consumes too much space (disks are full)
* This data costs too much to store (using too much cloud storage)


An admin should be able to delete the relevant blocks, bypassing the usual GC-race window, but (aside from that) in the safest possible way.

Given some collection PDHes...

For each PDH:
* Check for a collection with this PDH. If one exists, show a warning: this means "expedited delete" for this collection is a no-op.
* Use the logs table to get the manifest text for this PDH.

Perform a keep-balance operation, but
* Don't compute changes for all blocks -- only the ones appearing in the manifests retrieved above.
* When checking the logs table for recently referenced blocks (see #9363), skip collections with any of the supplied PDHes.
* When deciding whether to delete blocks, use the most recent timestamp of the collections being deleted rather than {now minus signatureTTL} as the race window threshold.
* Use the (new) "synchronous delete, ignoring timestamp" feature of keepstore instead of sending a trash list.
* Don't process any "pull" operations.

This could be presented as a separate command ("keep-force-delete"?) if keep-balance is refactored into a module. Alternatively, it could be a runtime option for keep-balance. It will use the same configuration file as keep-balance (along with other options).

refs: [[Expedited delete]] and [[Expiring collections]]

Back