...
The Crash-Consistent snapshot contains an immediate state of the disk. As if there was a power cut-off at the point of
snapshot creation. Whatever was in memory is lost. For modern applications robust applications, Crash-Consistent snapshots are enough
because they are designed to tolerate power cut-offs.
The application-consistent snapshot is created with the collaboration of the app running in the VM. Of course,
the
application needs to be aware of the snapshot being taken to flush all the data before it happens.
...
At a minimum, we need to make it clear that the custom application need needs to make sure it can be restarted from an
arbitrary snapshot, but we don’t have much confidence that will be sufficient. If there was an API where EVE-OS
would tell the app instance “flush all of your application buffers now; snapshot will be taken” followed by EVE-OS
doing the snapshot and then calling an API to tell the app instance “snapshot was done”.
...
In the VM-initiated snapshot, an application running in the VM would ensure it flushed the latest states on the disk,
and talked to handshake to the Local Profile Server to initiate the snapshot. This is the most straightforward approach for us, but
has its drawbacks - once the flush operation is completed, the system is allowed to continue write operations.
This means that once we rolled back to one of the snapshots, the filesystem would likely have to use its fault-tolerance
the mechanism as if a sudden power-off happened. But at least, it will be guaranteed that it has the latest data from
the application.
...