Feature #9364
Updated by Tom Clegg almost 8 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]]