1952550 - To reduce cleanup overhead at origin init, consider restricting use of marker file to when there mutations have been made, possibly tracking in-flight mutations with an RAII that can remove the marker when all mutations are completed

Status: NEW

(Core :: Storage: Cache API, enhancement)

Description

[Andrew Sutherland [:asuth] (he/him)]

It came up in discussion of https://phabricator.services.mozilla.com/D240734 about how often we call BodyDeleteOrphanedFiles that while we only perform cleanup if the marker file exists at origin init, the marker file exists for the entire time the Context exists, and this covers read-only access patterns as well as mutations. While we could delay the creation of the marker file until the first mutation occurs (and this could be a good first step), this wouldn't help for patterns with occasional mutations, such as for a ServiceWorker that caches previously unseen URL requests and periodically evicts old data. And a time-based heuristic isn't sufficient since situations like an orphaned cache or a referenced-but-deleted Response can persist for a very long time and we need to deterministically know whether there is currently some pending action that would need to be cleaned up on next start.

Comment 1

[Jens Stutte [:jstutte]]

I wonder if we could use our mechanism of directory locks to flag when a directory may be considered to be potentially dirty.