Fields

• lgrDiskPolicy :: HKD f DiskPolicy
   
• lgrGenesis :: HKD f (m (ExtLedgerState blk))
   
• lgrHasFS :: SomeHasFS m
   
• lgrParams :: HKD f LedgerDbParams
   
• lgrTopLevelConfig :: HKD f (TopLevelConfig blk)
   
• lgrTraceLedger :: Tracer m (LedgerDB' blk)
   
• lgrTracer :: Tracer m (TraceEvent blk)
   

Fields

• rollbackMaximum :: Word64
   
• rollbackRequested :: Word64
   

Fields

• annLedgerState :: LedgerDB l r

  The ledger DB just before this block was applied

• annLedgerErrRef :: r

  Reference to the block that had the error

• annLedgerErr :: LedgerErr l

  The ledger error itself

Fields

• ledgerDbSecurityParam :: SecurityParam

  Security parameter (maximum rollback)

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 Nothing if none was taken yet. Note that Nothing 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 defaultDiskPolicy