Hello, i have deleted the container in order to adjust a setting on it via the CLI.
After restarting container with docker run adjusted command my disk activity report about 99% activity.
How to bypass this ? (This process use my disk…) Is it normal ? Would it be possible to avoid this in future versions ?
Thanks.
PS : iam on raspberry pi 4
I wouldn’t say it’s normal to do this extensive disk scan (and multiple times!) but that’s how it’s currently implemented. On my full 6TB node it used to take 10-20 hours at full disk IO utilization.
P.S. Today I recompiled my raspbian kernel with bcache module enabled. I’ll write a separate post about the outcome
The storagenode doesn’t have any way to figure out is it a fresh database or recovered after failure except simply go an check the disk as source of truth.
На русском
Узел не знает, потерял он базу данных или нет. Она просто пустая или неполная (восстановленная). У него нет никакого другого способа убедиться, что данные есть, кроме как просканировать их
I wish storagenode asked before starting IO intensive operations like that. Hard drives are the slowest thing in a modern computer. This is one of the reasons I keep storj on separate drives - can’t spare the iops for these scans or cp+rm on delete (this one is wrong on so many levels).
The database could be corrupted by your configuration, not by the node: for example, the unplanned lost of power and you have a write cache enabled on that disk, or you (or OS) is killed the docker container without a timeout, your disk has errors and so on.
The node stores its state in the databases. If the database got corrupted or cleared by operator the node will not know the previous state.
На русском
Базу повреждает не узел, а ваша конфигурация. Например - внезапное отключение электроэнергии и использование кэша записи, либо убивание контейнера без ожидания.
Узел хранит состояние и информацию в базах данных. Если база данных повреждена или пустая - у него нет источника информации.