Vulncheck / Vulncheck (pull_request) Successful in 6m1sDetails
Build / Build Components (1.21) (pull_request) Successful in 7m37sDetails
Build / Build Components (1.20) (pull_request) Successful in 7m52sDetails
Tests and linters / Staticcheck (pull_request) Successful in 8m56sDetails
Tests and linters / Lint (pull_request) Successful in 9m26sDetails
Tests and linters / Tests (1.21) (pull_request) Successful in 15m5sDetails
Tests and linters / Tests with -race (pull_request) Successful in 15m7sDetails
DCO action / DCO (pull_request) Successful in 1m1sDetails
Tests and linters / Tests (1.20) (pull_request) Successful in 4m1sDetails
Badger implementation isn't tested and works not well,
but requires human resources to maintain.
Signed-off-by: Dmitrii Stepanov <d.stepanov@yadro.com>
There is a need to limit disk space used by write-cache. It is almost
impossible to calculate the value exactly. It is proposed to estimate the
size of the cache by the number of objects stored in it.
Track amounts of objects saved in DB and FSTree separately. To do this,
`ObjectCounters` interface is defined. It is generalized to a store of
numbers that can be made persistent (new option `WithObjectCounters`). By
default DB number is calculated as key number in default bucket, and FS
number is set same to DB since it is currently hard to read the actual value
from `FSTree` instance. Each PUT/DELETE operation to DB or FS
increases/decreases corresponding counter. Before each PUT op an overflow
check is performed with the following formula for evaluating the occupied
space: `NumDB * MaxDBSize + NumFS * MaxFSSize`. If next PUT can cause
write-cache overflow, object is written to the main storage.
By default maximum write-cache size is set to 1GB.
Signed-off-by: Leonard Lyubich <leonard@nspcc.ru>
Dmitrii Stepanov
Alejandro Lopez
Evgenii Stratonikov
Evgenii Stratonikov
Pavel Karpy
Leonard Lyubich