Fields

• dsNumber ∷ Word64

  Snapshots are numbered. We will try the snapshots with the highest number first.

  When creating a snapshot, we use the slot number of the ledger state it corresponds to as the snapshot number. This gives an indication of how recent the snapshot is.

  Note that the snapshot names are only indicative, we don't rely on the snapshot number matching the slot number of the corresponding ledger state. We only use the snapshots numbers to determine the order in which we try them.

• dsSuffix ∷ Maybe String

  Snapshots can optionally have a suffix, separated by the snapshot number with an underscore, e.g., 4492799_last_Byron. This suffix acts as metadata for the operator of the node. Snapshots with a suffix will not be deleted.

Fields

• snapshotBackend ∷ SnapshotBackend
   
• snapshotChecksum ∷ CRC
   

Fields

• spaInterval ∷ !SnapshotInterval
   
• spaNum ∷ !NumOfDiskSnapshots
   

Fields

• onDiskNumSnapshots ∷ Word

  How many snapshots do we want to keep on disk?

  A higher number of on-disk snapshots is primarily a safe-guard against disk corruption: it trades disk space for reliability.

  Examples:

  • 0: Delete the snapshot immediately after writing. Probably not a useful value :-D
  • 1: Delete the previous snapshot immediately after writing the next Dangerous policy: if for some reason the deletion happens before the new snapshot is written entirely to disk (we don't fsync), we have no choice but to start at the genesis snapshot on the next startup.
  • 2: Always keep 2 snapshots around. This means that when we write the next snapshot, we delete the oldest one, leaving the middle one available in case of truncation of the write. This is probably a sane value in most circumstances.
• onDiskShouldTakeSnapshot ∷ Maybe DiffTime → Word64 → Bool

  Should we write a snapshot of the ledger state to disk?

  This function is passed two bits of information:

  • The time since the last snapshot, or NoSnapshotTakenYet if none was taken yet. Note that NoSnapshotTakenYet merely means no snapshot had been taking yet since the node was started; it does not necessarily mean that none exist on disk.
  • The distance in terms of blocks applied to the oldest ledger snapshot in memory. During normal operation, this is the number of blocks written to the ImmutableDB since the last snapshot. On startup, it is computed by counting how many immutable blocks we had to reapply to get to the chain tip. This is useful, as it allows the policy to decide to take a snapshot on node startup if a lot of blocks had to be replayed.

  See also defaultSnapshotPolicy

Fields

• getFlag ∷ Bool