File tree Expand file tree Collapse file tree 1 file changed +33
-0
lines changed
Expand file tree Collapse file tree 1 file changed +33
-0
lines changed Original file line number Diff line number Diff line change @@ -331,3 +331,36 @@ response:
331331```
332332oasis1qqncl383h8458mr9cytatygctzwsx02n4c5f8ed7
333333```
334+
335+ ## storage
336+
337+ ### compact-experimental
338+
339+ Run
340+
341+ ``` sh
342+ oasis-node storage compact-experimental --config /path/to/config/file
343+ ```
344+
345+ to trigger manual compaction of consensus database instances:
346+
347+ ``` sh
348+ {" caller" :" storage.go:310" ," level" :" info" ," module" :" cmd/storage" , \
349+ " msg" :" Starting database compactions. This may take a while..." , \
350+ " ts" :" 2025-10-08T09:18:22.185451554Z" }
351+ ```
352+
353+ If pruning was not enabled from the start or was recently increased, then even
354+ after successful pruning, the disk usage may stay the same.
355+
356+ This is due to the LSM-tree storage design that BadgerDB uses. Concretely,
357+ deleting a key only marks it as ready to be deleted (a tombstone entry). The
358+ actual removal of the stale data happens later during the compaction.
359+
360+ During normal operation, compaction happens in the background. However, BadgerDB
361+ is intentionally lazy, trading write throughput for disk space among other
362+ things. Therefore it is expected that in case of late pruning, the disk space
363+ may stay constant or not be reclaimed for a very long time.
364+
365+ This command gives operators manual control to release disk space during
366+ maintenance periods.
You can’t perform that action at this time.
0 commit comments