[RFC] Umbra: physical remapping, protection mechanisms, and write amplification

Hi hackers,

I want to present one aspect of Umbra from a more fundamental perspective:
how the protection mechanism used for page persistence determines the
physical pages that must be persisted, and consequently the amount of
write amplification introduced by checkpoint processing.

I think it is useful to separate this discussion into two cases. First,
we can treat a checkpoint as a point in time and compare FPW / doublewrite
with Umbra. This isolates the protection mechanism itself. Then we can
extend the checkpoint from a point to an interval and discuss why Umbra
needs a different physical organization from a strict copy-on-write
scheme.

1. Checkpoint as a point: protection mechanism
------------------------------------------------

For the first comparison, assume that the checkpoint is a single logical
point. We do not yet discuss what happens while the checkpoint is running.
The question is simply: after a page is modified, what physical state must
be persisted to make the update crash-safe?

With an in-place update design, a logical page remains associated with a
fixed physical location:

L -> A

Updating L therefore means overwriting A:

L -> A
|
| overwrite
v
NEW

The problem is that the physical overwrite of a database page is not
necessarily atomic. Therefore, the protection mechanism must preserve a
complete page through an additional persistence path.

For PostgreSQL FPW, a full-page image is recorded in WAL after the first
modification following a checkpoint. The data page can then be written to
its normal physical location, and recovery can use the full-page image if
the data-page write was torn.

For InnoDB doublewrite, the complete modified page is first persisted to
the doublewrite area and is then written to its real physical location.
If the real page is torn, the complete page in the doublewrite area can be
used for recovery.

Although FPW and doublewrite implement the protection differently, they
share the same fundamental property: the protection mechanism for an
in-place overwrite requires an additional persistence path for a complete
page.

Conceptually:

FPW / Doublewrite

modified page
|
+-----> additional full-page protection state
|
+-----> real physical page

The additional physical page or full-page image is therefore not an
incidental optimization. It is part of the protection mechanism itself.

Umbra changes this protection mechanism. Instead of requiring the old
physical page to be overwritten and then protecting the modified page with
an additional full-page copy, Umbra establishes a protected physical state
at checkpoint time.

checkpoint
|
v
protected physical state
|
v
old physical page remains available

A later modification can then be represented by a different physical
location and a change in the logical-to-physical mapping:

before:

L -> A
|
v
OLD

after:

L -> B
|
v
NEW

A
|
v
OLD

The important point is that A is not a temporary backup copy created only
for the new modification. It is the existing physical version that has
already been retained by the checkpoint protection mechanism.

Thus the fundamental difference is the protection mechanism itself:

FPW / Doublewrite:
protect an in-place overwrite by establishing
an additional full-page persistence path.

Umbra:
establish the protected physical state at checkpoint time,
and retain that physical state as part of the protection scheme.

2. Why the protection mechanism changes write amplification
---------------------------------------------------------------

The checkpoint itself does not disappear in Umbra. Both systems still have
to flush dirty buffered state as part of checkpoint processing. The
important difference is how much physical data the protection mechanism
requires the checkpoint to persist.

With FPW / doublewrite, checkpoint processing is accompanied by the
additional full-page persistence required by the protection mechanism.
For a typical 8 KB or 16 KB database page, that additional protection path
is itself another full-page write or full-page image persistence.

Conceptually:

FPW / Doublewrite:

checkpoint
|
+---- dirty page -> real physical page
|
+---- dirty page -> full-page protection state

approximately:
one full page of data
+ one additional full-page persistence path

Umbra uses a different physical organization. The checkpoint can flush the
buffer contents to the protected physical page, while the new physical
location is established through the logical-to-physical mapping. The new
location therefore does not require another full copy of the buffer contents
merely to establish the mapping.

Conceptually:

Umbra:

checkpoint
|
+---- dirty buffer -> protected physical page
|
+---- remap metadata -> new physical location

The exact metadata representation and persistence ordering are
implementation details, but the important asymmetry is that the additional
operation is metadata-sized rather than another 8 KB or 16 KB full-page
copy.

Therefore, the write-amplification reduction is a direct consequence of
the protection mechanism. The checkpoint still performs writeback, but the
protection mechanism no longer turns page-level safety into another full-
page persistence operation.

The resulting performance path is:

protection mechanism
|
v
physical pages that must be persisted
|
v
checkpoint / writeback volume
|
v
storage I/O pressure
|
v
contention with foreground transactions
|
v
transaction latency
|
v
tpmC

This is the logical point at which a tpmC improvement should appear. The
transaction itself has not become computationally cheaper, and the logical
set of database updates has not been reduced. Instead, the same workload
causes less physical persistence work during checkpoint processing. With
less writeback pressure and more storage bandwidth available to foreground
transactions, persistence-related contention and latency can decrease,
which can translate into higher tpmC.

The key observation is therefore not simply "Umbra writes once while
FPW/doublewrite writes twice." Rather, the number of physical pages that
must be persisted is a consequence of the protection mechanism, and the
resulting physical write volume is what creates the write-amplification and
checkpoint-I/O difference.

3. Checkpoint as an interval: COW versus Umbra
------------------------------------------------

The previous comparison deliberately treated the checkpoint as a point so
that the protection mechanisms could be compared directly. Once the
checkpoint is viewed more realistically as an interval, a second question
appears:

What happens when a page is modified while the checkpoint is in
progress?

Consider:

Checkpoint Start Checkpoint End
| |
+-----------------------------------------+
checkpoint interval

A strict copy-on-write design can handle this by ensuring that the old
physical page remains untouched after the checkpoint has protected it:

old physical page
|
| protected
|
+---- page modified
|
v
new physical page

In this model, the old physical page is preserved and all subsequent
modifications are directed to a new physical location.

Umbra does not need to impose this strict rule for every page and every
modification during the checkpoint interval. The checkpoint is a range of
time rather than a single instant, and correctness does not require that
every modification after the checkpoint boundary must be forced to a new
physical page.

A page modified during the checkpoint interval may still be flushed to an
old physical location depending on the checkpoint state and the chosen
write path. This does not by itself violate correctness because WAL redo is
idempotent: replaying the corresponding update after the data page has
already incorporated it does not change the logical result.

Therefore, the purpose of Umbra's remapping is not simply to enforce COW on
every update. The deeper purpose is to separate logical page identity from
physical location so that the checkpoint can define which physical state
must remain protected while physical placement remains flexible.

4. Why logical/physical separation matters
--------------------------------------------

COW is a possible way to create a new physical version, but COW alone is
not the fundamental abstraction needed by Umbra.

If a logical page is permanently identified with one physical address,
then creating a new physical copy is not enough. The system also needs a
way to make the logical page refer to the new location.

Umbra therefore separates the two identities:

Logical Page L
|
| mapping
v
Physical Page P

After an update, the mapping can change:

Logical Page L
|
v
Physical Page P_new

while P_old can remain available as a physical version until the
corresponding checkpoint generation is safe to reclaim.

This logical/physical separation is what makes physical remapping possible.
COW can be used as one strategy for producing new physical versions, but
COW is not the fundamental abstraction. The fundamental abstraction is that
logical identity and physical location are decoupled, allowing checkpoint
protection to be expressed in terms of physical generations rather than
fixed physical page addresses.

5. Summary
----------

The overall argument can be summarized as follows:

Checkpoint as a point
|
v
compare protection mechanisms
|
+-------------------------------+
| |
FPW / Doublewrite Umbra
| |
in-place overwrite protected physical state
| |
additional full-page existing physical version
persistence path serves as protection
| |
+---------------+---------------+
|
v
physical pages persisted
|
v
write amplification
|
v
checkpoint I/O pressure
|
v
foreground contention
|
v
tpmC

Checkpoint as an interval
|
v
page modifications during checkpoint
|
+-------------------------------+
| |
COW Umbra
| |
strict new-page physical remapping
placement + logical/physical separation
|
v
physical generations

In this sense, Umbra is not simply a cheaper implementation of FPW or
doublewrite. The primary change is the protection mechanism itself. That
mechanism determines the physical pages that must be persisted, which in
turn determines write amplification and checkpoint I/O pressure. The
logical/physical separation then provides the flexibility required to
apply physical remapping over a checkpoint interval without reducing the
design to strict COW semantics.

Best,
Mingwei Jia