i tried to update my Storj Node yesterday but i got two errors.
First this: Error: Error during preflight check for storagenode databases: storage node preflight database error: heldamount: expected schema does not match actual: &dbschema.Schema{
I´ve rename the heldamount.db
And then i got this Error
Error: Error during preflight check for storagenode databases: storage node preflight database error: storage_usage: expected schema does not match actual: &dbschema.Schema{
- Tables: []*dbschema.Table{
- s"Name: storage_usage\nColumns:\n\tName: at_rest_total\n\tType: REAL\n\tNullable: false\n\tDefault: \"\"\n\tReference: nil\n\tName: interval_start\n\tType: TIMESTAMP\n\tNullable: false\n\tDefault: \"\"\n\tReference: nil\n\tName: satellite_id\n\tType: BLOB\n\tNullable: false\n\tDefault: \"\"\n\tReference: nil\nPrimaryKey: interval_start satellite_id\nUniques:\n\t",
- },
+ Tables: nil,
Indexes: nil,
}
storj.io/storj/storagenode/storagenodedb.(*DB).Preflight:322
main.cmdRun:190
storj.io/private/process.cleanup.func1.4:359
storj.io/private/process.cleanup.func1:377
github.com/spf13/cobra.(*Command).execute:840
github.com/spf13/cobra.(*Command).ExecuteC:945
github.com/spf13/cobra.(*Command).Execute:885
storj.io/private/process.ExecWithCustomConfig:88
storj.io/private/process.ExecCustomDebug:70
main.main:320
runtime.main:203
2020-07-09T22:48:07.872Z INFO Configuration loaded {"Location": "/app/config/config.yaml"}
2020-07-09T22:48:07.878Z INFO Operator email {"Address": "xxxx"}
2020-07-09T22:48:07.878Z INFO Operator wallet {"Address": "xxxxx"}
2020-07-09T22:48:09.072Z INFO Telemetry enabled
2020-07-09T22:48:09.075Z INFO db.migration Database Version {"version": 42}
I´ve renamed the storage_usage db an restart storj with the same Error and Storj create a new storage_usage db.
I’ve change the Docker (without - v mount)
and i check my disk and Filesystem all ok, i got no errors…
If i Start the Storj Docker i got this:
2020-07-11T09:45:01.316Z INFO Configuration loaded {“Location”: “/app/config/config.yaml”}
2020-07-11T09:45:01.323Z INFO Operator email {“Address”: “xxx”}
2020-07-11T09:45:01.323Z INFO Operator wallet {“Address”: “yyy”}
2020-07-11T09:45:17.132Z INFO Telemetry enabled
2020-07-11T09:45:17.134Z INFO db.migration Database Version {“version”: 42}
2020-07-11T09:45:17.132Z INFO Telemetry enabled
2020-07-11T09:45:17.134Z INFO db.migration Database Version {“version”: 42}
2020-07-11T09:45:18.467Z INFO preflight:localtime start checking local system clock with trusted satellites’ system clock.
2020-07-11T09:45:19.326Z INFO preflight:localtime local system clock is in sync with trusted satellites’ system clock.
2020-07-11T09:45:19.326Z INFO bandwidth Performing bandwidth usage rollups
2020-07-11T09:45:19.326Z INFO Node 12pYbE71MqmW21tLN1U8GoLhVooL7YJG8LuvhQcPU5SeCruEu1s started
2020-07-11T09:45:19.326Z INFO Public server started on [::]:28967
2020-07-11T09:45:19.326Z INFO Private server started on 127.0.0.1:7778
2020-07-11T09:45:19.326Z INFO trust Scheduling next refresh {“after”: “7h7m39.71100414s”}
2020-07-11T09:45:19.326Z INFO preflight:localtime local system clock is in sync with trusted satellites’ system clock.
2020-07-11T09:45:19.326Z INFO bandwidth Performing bandwidth usage rollups
2020-07-11T09:45:19.326Z INFO Node 12pYbE71MqmW21tLN1U8GoLhVooL7YJG8LuvhQcPU5SeCruEu1s started
2020-07-11T09:45:19.326Z INFO Public server started on [::]:28967
2020-07-11T09:45:19.326Z INFO Private server started on 127.0.0.1:7778
2020-07-11T09:45:19.326Z INFO trust Scheduling next refresh {“after”: “7h7m39.71100414s”}
2020-07-11T09:45:35.027Z ERROR db Unable to read the disk, please verify the disk is not corrupt
I’m not that familiar with xfs specifically, but that clearly shows failed CRC checks and bad blocks. The wording also suggests you ran a diagnostic without repairing. “would rewrite/would reset/would have cleared”
Stop the node, unmount the file system and run xfs_repair on it. Don’t use the -n flag. (I wrote this before I was even sure you used it. But looking at your screenshot, it’s listed at the bottom. The -n flag makes it only check but not fix anything)
Looks good now, but do run that SMART check. You should be able to do that fine while online. If your HDD is indeed starting to fail, the problems will be back. It’s best to know beforehand.