Epoch System

[matthew-levan]

This PR implements a new format for how piers store their event logs on disk.

Resolves #313.

Design

Existing format:

./zod/.urb/log
├── data.mdb
└── lock.mdb

New format:

./zod/.urb/log
├── 0i0             # epoch dirnames specify the last event of the previous epoch
│   ├── data.mdb    # lmdb file containing events 1-132
│   ├── epoc.txt    # disk format version (this PR starts versioning at 1)
│   ├── lock.mdb    # lmdb lock file
│   └── vere.txt    # binary version this set of events was originally run with
└── 0i132
    ├── data.mdb
    ├── epoc.txt
    ├── lock.mdb
    ├── north.bin   #
    ├── south.bin   # snapshot files (state as of event 132), strictly read-only
    └── vere.txt

The new format introduces epochs, which are simply "slices" or "chunks" of a ship's complete event log. Above, you can see the ship's event log chunked into two epochs: 0i0 and 0i132.

New ships booted with the code in this PR instantiate their log directories with the new format. Existing piers are automatically migrated on boot.

Epoch "rollovers" (when the current epoch is ended and a new, empty epoch is created) occur under three conditions:

1. The pilot uses the new roll subcommand to manually rollover.
2. The pilot runs the chop subcommand.
3. We detect a different running binary version than the one pinned in the current epoch.

Both migrations and epoch rollovers ensure there's a current snapshot before running.

A few TODOs left:

• Iron out small kink in migration behavior for previously chopped piers
• Make sure correct binary version gets pinned to first epoch of migrated piers
• Rollover to new epoch when a new binary version is detected
• Make sure manual migration logic is idempotent
• Update prep command
• Fix chop so it works when there are 3 epochs starting with 0i0
• Reproduce and fix partially-deleted epoch 0i0 after chop
• Pair with someone to run manual GDB testing for migration idempotency and rollover logic
• Take a look at @joemfb's replay code and compare/find overlaps
• Document final system design in this PR
• Correct epoch naming scheme
• Make chop leave the latest two epochs
• Better error handling
• Better cleanup
• Test migration with real ships running on local-networking mode
• Test epoch rollover idempotency
• Test fresh boot
• Handle case where snapshot has been deleted from chk/
• Ensure u3_disk_epoc_good() is implemented and used how we want
• Ensure u3_disk_epoc_init() is implemented and used how we want
• Replay works with urbit play and urbit
• Replay works in edge case where only epoch 0 and no valid snapshot exist
• Move new-epoch-on-vere-version-mismatch logic to _pier_wyrd_init()
• Make subcommands which call u3_disk_init() auto-migrate
  • info
  • cram
  • queu
  • meld
  • pack
  • play
  • chop
  • roll
• Make replay on boot use u3_mars_play()
• Test migration from an old pier (again)
• Test migration from an old pier that needs a full replay (i.e., from beginning of its event log) first works
• Test that ./urbit roll zod with an updated binary version and an empty latest epoch, it does not roll but instead just updates the vere.txt file

[barter-simsum]

quick pass over. a few nits mostly.

[matthew-levan]

This is ready for final review and merge. @joemfb @belisarius222 @barter-simsum

[matthew-levan]

I think it's worth having the file extension to keep it separate from other instances of "vere" in the codebase.

…

On Tue, Jul 18, 2023 at 1:06 PM barter-simsum ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In pkg/vere/disk.c <#459 (comment)>: > + + u3_dire_free(die_u); + + return ret_o; +} + +/* u3_disk_epoc_vere: get binary version from epoch. +*/ +c3_o +u3_disk_epoc_vere(u3_disk* log_u, c3_d epo_d, c3_c* ver_w) +{ + struct stat buf_u; + c3_c* ver_c; + c3_w red_w, len_w; + c3_i ret_i, fid_i; + ret_i = asprintf(&ver_c, "%s/0i%" PRIc3_d "/vere.txt", but why add .txt? I would just call it vere — Reply to this email directly, view it on GitHub <#459 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AV2DQRAZD3JF6TMLVOL6MU3XQ27ARANCNFSM6AAAAAAZIHMTTY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[barter-simsum]

PMTS,N

[barter-simsum]

@joemfb to reapprove

[matthew-levan]

Ravioli, ravioli, give me the formuoli!

[joemfb]

this will do

[joemfb]

missing a trailing newline in this file