Disqualified after 2 hours of [edit] failed audits?

I take it that Raspberry Pi is no longer the recommended hardware? :slight_smile:

As I said - “if possible”.
For the Raspberry I would recommend the expansion cards, which are more robust than any integrated controller on any external disk. I uses my Raspberry Pi3 with this card and box:

The HDD is a normal 3.5" HDD (WDC WD20EZRZ), not the crap from the external case, which are offered by manufactures.
Working well since February 2019

1 Like

The USB drive worked for a long time for the OP too, until it didn’t :slight_smile: . Such systems (no RAID etc) usually work well for a relatively long time without problems, until the problems start.

Your link seems broken by the way.

Still - “avoid USB if possible” conflicts with “it is recommended to use RPi for the node”. Assuming the new operator has no hardware right now, avoiding USB would mean avoiding RPi as well.

I am just pointing out the inconsistencies, that’s all, no bad will. I have enough experience to come up with what I think is a good way to do it, but imagine a newbie reading those two recommendations together - “buy RPi, but avoid USB if possible” - the newbie could get confused.

had one usb work fine for almost a year too. until it didnt…

@Alexey, as far as I understand this will not help when the node is already running and the hard drive suddenly disconnects. Am I wrong?

:point_up_2: yeah, that’s exactly the problem :confused:

@Alexey The link doesn’t show the product anymore … so

Updated the link, seems they removed the item from the shop.

I do not see a contradiction here. Avoid using USB if possible.
If it is not possible you obviously can’t do it. I address more PC with external USB drive. In case of PC you have a choice - use internal or external drive. The internal is a best.
In case of Rpi you do not have a choice, so avoiding use of USB for connecting drive is not possible.
But even there it’s better to use the expansion board and normal CMR 3.5" drive.

It is not possible to avoid USB with a Raspberry, but it is possible to use something else that does not require USB.
Let’s say a newbie asks you something like this: “Should I use a Raspberry with USB or something else that does not require USB? What that ‘else’ would be?”.
At least this is where I see the contradiction - recommendation 1 suggests a setup that recommendation 2 says could be bad.

usb is created to be disconnected… it’s not a bug… IT’S A FEATURE xD

maybe people should stop buying RPI for storagenodes… at the very least get something with access to a pci/pcie bus or have a sata controller…
i know they are popular, but they seems so ill equipped for being a storagenode that imo making them actually work well as one, would cost more than better solutions in one package.

Either way, I get disqualified for a “software” bug because my disk got offline the first time in 4 years… and I still don’t know if I can format all the data thats just sitting there perfectly fine and disqualified ??

I’m in this project since the first tests but if it’s such a risk to loose anything you slowly collect then I will only be investing in the crypto storj. Hell , it’s a lot less risky to invest in a new crypto than this :joy:

Prio 1 fix!?

They’re working on preventing an unavailable storage location from causing disqualification. Though I think the focus is now on checking at startup of the node. There should be some form of monitoring and the node should simply go offline is the storage location is not available. I created a suggestion for just that here: Make the node crash with a fatal error if the storage path becomes unavailable
You can vote for that suggestion there as well. It sucks that nodes can now get disqualified for this. Although it is a failure of the hardware/OS/drivers, the node may not be able to fix the issue, but it can prevent itself from getting disqualified for it.

3 Likes

It’s not a bug in the storj software.

1 Like

I get people who say it’s not a bug, but come on… It is at the very least a situation where improvement is urgent I think!

Let’s upvote @BrightSilence’s idea :slightly_smiling_face:

2 Likes

How about this : https://geekworm.com/collections/raspberry-pi/products/raspberry-pi-x828-stackable-2-5-sata-hdd-ssd-shield

image

You have dual power supplies and if you lose both your pi dies too, so no DQ for lost usb.

It is total overkill and that is why I like it.

It does not protect against flaky connection or a problem with the USB->SATA converter or a problem with the USB controller or drivers.
As I understand, what happened to the OP was that the drive just “disappeared” not that its power supply failed or stuff like that.
Admittedly, the same can happen to normal SATA, but it is probably less likely.
RAID would protect against on drive disappearing, but how the stack in yuour post is organized if something happened to the top USB hub, all drives would be inaccesible.

1 Like

yeah i’m with pentium100 on this, there is a fundamental flaw in using usb for storagenodes…

  1. usb drives are rarely rated nor designed for 24/7 operation
  2. usb drives often take up a good deal of extra physical space because of big plastic casings.
  3. usb is designed to be disconnected… its not designed to run 100% stable… its designed to simply reboot and reload all devices, one cannot expect usb to be stable…
    sure your mouse and keyboard seem stable… but would you really notice a 50ms timeout once a day…

however with a storagenode remounting a drive… the drive letters / designations / mount folders and what not may cause issues… and all of a sudden you have a working usb bus, with a working external usb hdd connected… but it’s just not mounted correctly for the os and storagenode to speak to it…

sure it might work well having the 50ms time out… 100- or 300 times in a row… but eventually you will get unlucky… which is why your entire computer freezes when the hdd’s doesn’t respond…

everything else basically waits for the drive to reconnect so that nothing f’s up… just like zfs pools will pause all io to a pool upon failure… this is to prevent errors and avoid causing more trouble on disconnects than already was created by a drive having high latency or got disconnected… usb doesn’t care tho… its usb… its made for stuff to be able to disconnect and reconnect like a network…

you can “never” expect usb to do the work of dedicated hardware designed for other purposes and to believe you can… is like comparing a car to a motor cycle… sure in many ways they can do the same purpose… the motor cycle just doesn’t have the safety of a car…

sata is not great either for 24/7 operation HA operation… but it can work… fairly well… atleast its designed for it… partly… unlike usb

I would suggest to take a look on HC2:

Simply because I like its minimalism:

So! After my misfortune with disks disconnection, I thought I’d do something to make sure storj nodes shut down when something goes wrong.

@BrightSilence’s solution seemed pretty easy, so I gave it a go:

I put that in my crontab, and to make sure it works, I did something that apparently was stupid: I unmounted the disk to see whether the docker instance would correctly shut down.

The good news is: YES! It did shut down the node to prevent it from being disqualified :slight_smile:

The bad news is: It corrupted most of the database files of this node :cry:, which cannot start up anymore:

Checking 'storj_node_4'...
Checking file '/home/pi/storj/mounts/disk_3/storj_node_4/revocations.db':
Error: file is not a database
Checking file '/home/pi/storj/mounts/disk_3/storj_node_4/storage/bandwidth.db':
ok
Checking file '/home/pi/storj/mounts/disk_3/storj_node_4/storage/heldamount.db':
Error: file is not a database
Checking file '/home/pi/storj/mounts/disk_3/storj_node_4/storage/info.db':
ok
Checking file '/home/pi/storj/mounts/disk_3/storj_node_4/storage/notifications.db':
Error: file is not a database
Checking file '/home/pi/storj/mounts/disk_3/storj_node_4/storage/orders.db':
ok
Checking file '/home/pi/storj/mounts/disk_3/storj_node_4/storage/piece_expiration.db':
Error: file is not a database
Checking file '/home/pi/storj/mounts/disk_3/storj_node_4/storage/pieceinfo.db':
Error: file is not a database
Checking file '/home/pi/storj/mounts/disk_3/storj_node_4/storage/piece_spaced_used.db':
Error: file is not a database
Checking file '/home/pi/storj/mounts/disk_3/storj_node_4/storage/pricing.db':
Error: file is not a database
Checking file '/home/pi/storj/mounts/disk_3/storj_node_4/storage/reputation.db':
Error: file is not a database
Checking file '/home/pi/storj/mounts/disk_3/storj_node_4/storage/satellites.db':
Error: file is not a database
Checking file '/home/pi/storj/mounts/disk_3/storj_node_4/storage/storage_usage.db':
Error: file is not a database
Checking file '/home/pi/storj/mounts/disk_3/storj_node_4/storage/used_serial.db':
ok

Remind me why we’re using Sqlite3?
So now I’m trying to follow this article:

In the hope that it will fix my databases…
That worries me though: It means that in the event of a power outage, all database files can end up completely trashed, that’s pretty concerning :confused:

Storj is an exhausting frustrating amazing technical journey for sure! So many issues I did not even knew existed just for running one program! :sweat_smile:


Edit: Here is what the node says at boot time, for info:

2020-08-15T10:07:20.281Z        INFO    Configuration loaded    {"Location": "/app/config/config.yaml"}
2020-08-15T10:07:20.286Z        INFO    Operator email  {"Address": "..."}
2020-08-15T10:07:20.286Z        INFO    Operator wallet {"Address": "0x..."}
Error: Error starting master database on storagenode: storage node database error: file is not a database
        storj.io/storj/storagenode/storagenodedb.(*DB).openDatabase:272
        storj.io/storj/storagenode/storagenodedb.(*DB).openDatabases:202
        storj.io/storj/storagenode/storagenodedb.New:174
        main.cmdRun:150
        storj.io/private/process.cleanup.func1.4:353
        storj.io/private/process.cleanup.func1:371
        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:323
        runtime.main:203
2 Likes

When I am experimenting I just stop the storagenode and move all the database files.
Unless you want to mess around restoring dbs…

@andrew2.hart: I should have done that, you’re right.
On the other hand, it means it could happen to anyone, just because of a power outage…