Irmin_traces.Trace_replay_intf
module Config : sig ... end
include module type of struct include Config end
type _ return_type = _ Config.return_type =
| Unit : unit return_type
| Summary : Trace_stat_summary.t return_type
type 'a config = 'a Config.config = {
number_of_commits_to_replay : int;
path_conversion : [ `None | `V1 | `V0_and_v1 | `V0 ];
inode_config : int * int;
store_type : [ `Pack | `Pack_layered | `Pack_mem ];
replay_trace_path : string;
artefacts_path : string;
keep_store : bool;
keep_stat_trace : bool;
empty_blobs : bool;
return_type : 'a return_type;
gc_every : int;
gc_distance_in_the_past : int;
gc_wait_after : int;
add_volume_every : int;
}
Replay configuration
replay_trace_path
points to a specific file that describes the sequence of operations to replay. You may download one of the following URLs. The smaller ones are prefix of the larger ones.
number_of_commits_to_replay
is the wished number of commits to replay. If the value is too high, the replay will stop when reaching the end of replay_trace_path
. Pick a number of commits depending on the wished runtime. Here are some reference runtimes that were true for irmin 3.0:
60_457
commits take 3 minutes500_000
commits take 1 hour1_343_496
commits take 5 hoursartefacts_path
is the destination for the stats trace and the store. If both keep_store
and keep_stat_trace
are false, the destination will be emptied at the end of the replay.
path_conversion
is the strategy for shortening the paths while replaying. Was useful when benchmarking irmin on flattened Tezos paths.
empty_blobs
make the replay to push the empty string as in all the blobs, instead of their actual value read in the trace.
inode_config
is a pair of ints that will be stored in the results of the replay.
A GC is triggered every gc_every
commits. When GC is triggered, we select a previous commit that is gc_distance_in_the_past
commits away from the current head commit.
The first GC will be started after gc_distance_in_the_past + 1
commits were replayed. gc_distance_in_the_past
only makes sense if gc_every
is not 0
.
gc_wait_after
defines how many commits separate the start of a GC and the moment we block to wait for it to finish. 0
means that we will only block when the next gc starts or at the end of the replay. This parameter only makes sense if gc_every
is not 0
.
module type Store = sig ... end
module type Sigs = sig ... end