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>
It was needed before we started to flush during transition to
`degraded` mode. Now it is confusing.
Signed-off-by: Evgenii Stratonikov <evgeniy@morphbits.ru>
Make it store its internal `zap.Logger`'s level. Also, make all the
components to accept internal `logger.Logger` instead of `zap.Logger`; it
will simplify future refactor.
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Degraded mode allows us to operate without an SSD,
thus writecache should be unavailable in this mode.
Signed-off-by: Evgenii Stratonikov <evgeniy@morphbits.ru>
Allow user to initiate flushing objects from a writecache.
We need this in 2 cases:
1. During writecache storage schema update, it should be flushed with
the old version of node and started clean with a new one.
2. During SSD replacement, to avoid data loss.
Signed-off-by: Evgenii Stratonikov <evgeniy@morphbits.ru>