Object PUT, No space left about neofs-node HOT 6 CLOSED

do u clean data volume before start? If not, blobovnicza may store data from previous launches and incoming data overflows it

it'd be useful to see what size limit is configured (e.g. storage size limit debug (!) message in log head) and how big is your blobovnicza file (you can find it in data volume)

from neofs-node.

Updated description with init logs.

I clean data sometimes, when need clear env. Right now I can't check blobovnicza file size, because cleaned docker some time ago. About incoming data, we are talking about 30-40 files, where each was 17 bytes length.

When/if I have such error one more time, I will provide extra info to this issue

from neofs-node.

Frankly, I don't understand what is a "blobovnicza overflow". It's either out of disk space, or it should just work (expanding the DB or moving some data to file-backed blobstor). Yes, we can tune AIO for now, but it's still a problem long-term, consider someone operating a mainnet node and getting similar errors, it's gonna be a really nice puzzle for him.

from neofs-node.

currently, blobovnicza tree has fixed width so that you can predict the object location using HRW. It's very complicated (in both code and FS structure), so i suggest, to reduce the likelihood of new problems, simply switch to the file tree when all blobovniczas are full. This will prevent service failures.

Later, i propose to revise blobovnicza tree concept. It is difficult to maintain, and the performance is highly questionable. We will probably be able to store everything in one instance of the database, configuring it for a specific task. We should also explore other approaches of "micro" file storage. At the moment it has not been proven that the current implementation is the most optimal and convenient

thoughts? @roman-khimov @carpawell

from neofs-node.

One per-shard DB of this kind should be sufficient if managed appropriately, current tree structure makes little sense for the task.

from neofs-node.

i'll make draft changes with single DB approach. The most tricky part will be migration...

from neofs-node.