Disqualification for downtime vs. containment mode

Node Operators FAQ
,
1

Good morning,

today I should receive a new CMR HDD which will be connected to a SATA port. The current drive is SMR USB3 but connected to USB2. That should bring a great boost to my node.

I intended to migrate data live with rsync but the drive is very slow and USB2 interface won’t help. The migration could last for weeks adding more load to the already overloaded drive.

So I’m evaluating if it’s better to shut down the node, transfer the old disk to my laptop which has USB3 and rsync to the new disk offline in order to speed up the process.

I’ve read something about containment mode and disqualification for being offline too long, so I were wondering if the containment mode has been implemented or not and which is the maximum time a node can stay offline before being disqualified.

Thanks

2

Downtime disqualification is not yet live, but you should still keep down time as short as possible. You may also want to consider running a node on each HDD. This would cut the load on each individual HDD in half and may just be enough to keep running both.

3

Thanks for the answer. Keeping the downtime as short as possible is my objective, also because it has an impact on my node’s reputation.

I’ll perform a quick test (i.e. 10 minutes transfer) both online and offline to compare speeds and then I will decide the best approach.

1 Like
4

Lower your space allocation so that your node is full. Then it only has to serve the little bit of download. That reduces the load on your HDD significantly and might be enough to rsync while the node is running. Might still take forever with USB2.0 though…

5

Thanks, already done some days ago, I’m also getting a lot of DELETEs, so the used space shrunk a little bit in the last days.

6

Update: I decided to move the storage off-line. After a couple of tests the expected migration time was 3 days off-line and 37 days on-line, with the latter approach risking continuous suspensions due to increased database locks probability.

So, all went well, rsync worked flawlessly for three consecutive days and now my node has been migrated to the new hardware. I just started the node and immediately started to receive requests with a very high rate!

  • Old setup: Orange Pi PC2 + 4TB 2.5" USB Western Digital HDD (USB3 but connected to USB2)
  • New setup: Odroid HC2 + 8TB 3.5" Seagate IronWolf connected to SATA port

Thanks for anyone who helped me, now the Storj network is a little bit more performant.

Side consideration: my first intention was to use my spare capacity, which I had, to run the node, that’s also what suggested by Storj, I ended up buying new hardware. :slightly_smiling_face:

2 Likes