Graceful exit (mission impossible)

Hello to all programmers! And ordinary people!

Looking at these traffic spikes of the storage node in graceful exit mode - it’s more like a “dramatic exit” than a graceful one! :smile:

That 220k peak is especially entertaining - looks like the node decided to go out with a bang, doing a “here’s-all-my-data-take-it-or-leave-it” kind of farewell :performing_arts:

Those multiple peaks make it seem like the node can’t decide whether to leave quietly or throw a grand finale party. It’s like the storage node version of “thanks for all the fish” :dolphin:

Talk about making a memorable exit - this node definitely knows how to leave an impression on the network! :door::dash:

Why not make the return speed as high as possible?

Hello @peps,
Welcome back!

We re-implemented a Graceful Exit more than a year ago (Graceful Exit Guide (new procedure as of 2023-10-?)), it now doesn’t upload data to other nodes and doesn’t update the status until 30 days would pass. If your node was online with an online score not less than 80% it will succeed otherwise - disqualified.

So, that usage is a usual customers’ usage, maybe there is also a repair traffic, too.
You may check your logs for sure.

Currently I’m at 95% score. The server hosted at my location costs $80/month in electricity, the internet is $100/month, and your node is paying only $10/month.

Since it’s not reasonable for me to run your node at a huge loss, I started Graceful Exit but for 8TB of stored data I may not see the economic value in waiting around for that process to complete and I have economic incentives to simply destroy the Storj Volume.

What is my incentive to keep running until graceful exit completion?

There are none. I would have (and did) rm -rf’'ed perfectly good nodes whenever I simply needed to get back some of the space. The whole “do anything for a month for $10” is simply preposterous

The incentives don’t need to work on everyone – they just need to nudge the behavior enough on average to get the required per-node average durability. Evidently, the current system accomplishes that well enough.

1 Like

This is why we always recommend to use only what you have now and what’s will be online with Storj or without. Only in this case any income is a pure profit.

To receive a held amount back. Some use “to be nice” as an incentive - it’s up on you.

1 Like

The held back amount is less than the cost of keeping it running for the month so I’m more profitable by simply deleting and shutting off the server to conserve power.

You guys have only yourselves to blame for this scenario by your cutting the compensation in half.

Graceful exit is a moot point if node operators are shelling out of pocket due to your rate cuts.

No, you completely misunderstand.

Read Alexeys comment above carefully.

Joining the project without trying to understand it and then complaining when things don’t go according to your uninformed opinion about how things should work is hardly productive.

This is not news and has been repeated many times on the forum and in the documentation.

To address this your concern:

If storj keeps your server online you are already in the wrong here. Shut it down. You should have not been running it in the first place, let alone to get held amount.

If you run your server anyway for other reasons but want to stop participating as a node operator and don’t need to reclaim space right now — there are no reason not to do graceful exit.

2 Likes

Awesome!
For me it’s terrible! Does this make any of the users feel more comfortable? It looks like no one will wait that long, the money will just “disappear”! But we understand who will get it)

1 Like

It will be spent restoring the durability of the data your node lost

Correct, other node operators.

Not getting free $10 that were never yours to begin with is terrible? How so? And besides, you have agreed to this (forfeiting held amount when exiting network abruptly) when you accepted tos and started the node. So I’m not sure what point are you trying to make?

1 Like

"Dear sir, you not only confused MY $10 with YOURS, but you also decided to hold onto them for another 30 days! It’s like taking someone else’s umbrella and saying: ‘I’ll return it in a month when the rainy season ends’ :umbrella:

My disk is already wheezing like an old vacuum cleaner, and you’ve sentenced it to another month of hard labor! It’s like telling a dying battery: ‘Just work a little longer, only 720 hours to go!’ :battery:

Terms of Service, you say? Well… I can write conditions too: ‘By reading this text, you automatically owe me a million!’ How do you like that agreement? :moneybag:

P.S. My disk is already at retirement age, it needs to go on well-deserved rest, but you’re like: ‘30 days without the right to early release!’ It’s like some kind of strict regime sanatorium! :sweat_smile:"

The 30 days requirement was always there. Just earlier implementation also used your bandwidth to unload data from your node to other nodes. The latest implementation just requires your node to be online as usual, no additional traffic is produced, than the usual customers usage.

These 30 days are needed to help repair data using your node, if there are segments with the low amount of healthy pieces and your node contains some of them. This would be rewarded with your held amount + regular payout for the usage during the graceful exit period.

If the node would exit abruptly or disqualified during graceful exit period, the held amount will be used to repair data on other nodes (they will be compensated for the egress repair traffic from that held amount).

2 Likes