Hi Kjell,

>> Yes. Nbackup was designed in such a way that the database remains
>> fully operational during the "merge" state.
>> Writes go the the main file, reads are taken from both main and
>> delta and then compared for freshness.
>
> Nice. What about writes that affect parts of the databse that are newer
> in the delta than in the main file? I assume it's solved somehow...

Those writes too are written to the main file.

This is from the original description by the developers (main developer
was Nickolay Samofatov):

===
The backup state cycle is:

nbak_state_normal -> nbak_state_stalled -> nbak_state_merge
-> nbak_state_normal

* In normal state writes go directly to the main database files.
* In stalled state writes go to the difference file only and the main
files are read only.
* In merge state new pages are not allocated from difference files.
Writes go to the main database files. Reads of mapped pages compare
both page versions and return the version which is fresher, because
we don't know if it is merged or not.

This merge state logic has one quirky part. Both Microsoft and Linux
define the contents of file growth as "undefined" i.e., garbage, and
both zero-initialize them.

This is why we don't read mapped pages beyond the original end of the
main database file and keep them current in difference file until the
end of a merge. This is almost half of nbak fetch and write logic,
tested by using modified PIO on existing files containing garbage.
===


Paul Vinkenoog