/**
 * Assumed worst-case replay floor, in bytes per millisecond (4 MB/s).
 *
 * Calibrated against measurements, deliberately far below all of them:
 *   - 1,365,347,557 B replayed in 6.60s  = 206,823 B/ms (~197 MB/s)
 *   -    96,410,208 B replayed in 2.77s  =  34,806 B/ms (~35 MB/s)
 *   - the issue's slowest field report, 2.5 GB in 85s = 30,000 B/ms (~30 MB/s)
 *
 * 4,000 B/ms is 7.5x under the slowest observation, so the derived deadline
 * errs heavily toward waiting rather than killing a working process. It is a
 * FLOOR, not an estimate — being wrong in this direction costs boot latency,
 * being wrong in the other direction takes the node down permanently.
 */
export declare const WAL_REPLAY_FLOOR_BYTES_PER_MS = 4000;
/**
 * Total bytes of RocksDB write-ahead log retained in `location`.
 *
 * Best-effort by construction: this runs on the boot path, so a missing
 * directory, a permissions error, or RocksDB deleting a segment mid-scan must
 * contribute 0 rather than throw. Returning 0 degrades to today's behaviour
 * (the base timeout, unchanged) — never to a failed boot.
 */
export declare function measureRetainedWalBytes(location: string): number;
/**
 * Derive the readiness deadline from the replay work actually pending.
 *
 * `walBytes === 0` returns `baseMs` UNCHANGED. That identity is what preserves
 * today's fast-fail for the common case (a genuinely broken binary, a bound
 * port, a bad `--location`) — the extension only applies when there is real
 * recovery work to wait for.
 */
export declare function resolveWalAwareReadyTimeoutMs(input: {
    baseMs: number;
    walBytes: number;
}): number;
/** Human-readable byte size for operator-facing log lines. */
export declare function formatWalBytes(bytes: number): string;
//# sourceMappingURL=oxigraph-wal.d.ts.map