How Docker and OCI image layers represent filesystem changes, why deleting a file needs special whiteout entries, and what happens if you create a file called .wh.foo.
Whiteout is a really common term for any kind of merged dictionary (filesystem or otherwise) where a newer layer needs a mechanism for deleting an entry from an older one. And it’s another one of these culture-specific terms leaking into generic discourse.
Huh, I admit I’ve never heard “whiteout” used to describe this! TIL.
By the way, I consider traditional tombstones as the in-place version, and the tombstone concept thereby captures the same idea for me when applied append-only in LSM-like data structures (except perhaps for an in-place level 0, e.g. the memtable in an LSM store). Append-only deletions via tombstones is in the original Bentley-Saxe paper on decomposable search problems. And similar to how tombstone slots are garbage collected implicitly (same idea as a copying or compacting GC) when rehashing a hash table (which I’m guessing is where most people know tombstones from), the same applies to LSM sort-merges, or RH hash table sort-merges, generalizing the rehashing idea.
Huh, I admit I’ve never heard “whiteout” used to describe this! TIL.
By the way, I consider traditional tombstones as the in-place version, and the tombstone concept thereby captures the same idea for me when applied append-only in LSM-like data structures (except perhaps for an in-place level 0, e.g. the memtable in an LSM store). Append-only deletions via tombstones is in the original Bentley-Saxe paper on decomposable search problems. And similar to how tombstone slots are garbage collected implicitly (same idea as a copying or compacting GC) when rehashing a hash table (which I’m guessing is where most people know tombstones from), the same applies to LSM sort-merges, or RH hash table sort-merges, generalizing the rehashing idea.
score 2 · canonical