Why limit the ability to shrink nodes? SNO could make an error and not enough data will be removed. SNO might want to shrink node multiple times to make space for own data. Storj allows people to rent out hardware resources they already own and run, so allowing people to free their own resources is a natural feature to have in this case.
I don’t see how the process can impact the network. Satellites decide which data gets moved and where to.
To prevent this…
and encourage running long term reliable nodes.
But you don’t know which data will be removed and what kind of data will be added, and when. Meanwhile other nodes will be paid for storing the data pulled from your node.
You’ll at least be able to pick the satellite. I think it’s just important to discourage people from trying to manipulate that stuff. Also keep in mind that while the satellites don’t have to pay nodes for this traffic, they do have to pay for cycles and traffic used to coordinate the transfers. It’s not free for satellites. Additionally the satellites need to be able to count on some level of storage space availability. If nodes can keep shrinking over and over it gets a lot harder to determine how much space is actually available. Limiting how often you can do this forces SNOs to plan ahead and assign space that will be available for a while. Instead of every free byte and having nodes that shrink every day because of other usage.
If you don’t limit it people are going to script the shrinking. Leading to a lot of GE traffic and overhead on the network. Rather than just offer a little less space to begin with so data ends up on nodes where it can likely stick around for longer.
This can be prevented by preventing the SNO to increase the allocated storage for a while after the partial GE. OR even preventing the SNO from getting any new data at all for a while (even if some data was deleted by the customers after the partial GE).
When someone needs to free up the space, he probably needs that space as soon as possible, with the only options the partial GE or a full GE (or just shut the node down and delete the data). On the other hand, even if the SNO later gets some more capacity, there is no urgency to expand the node, so he can wait the two or six months or whatever.
This is a local setting. I don’t see how a satellite could enforce that.
That would work. But I don’t think you want to do that for half a year. Significant deletes can happen and you would want to be able to use that space.
Since the partial GE would have to be triggered for a specific set of satellites you could always just pick one satellite to shrink and have others to shrink if you want to shrink the size again. You’d still have quite a few options that way. I don’t think it’s so bad to enforce SNOs to predict future needs so things can remain relatively stable over time.
The satellite could ignore the new setting, as I remember the node reports its space to the satellite, but if it only reports (enough/not enough space) then yeah, restricting that would be more difficult, but still possible.
After the partial GE, the satellite does not give the node any new data, unless some data was deleted by the customer, in which case, give as much data as was deleted. Basically, tracking the space based on deletes/uploads.
It could be two months or whatever, as long as it no longer makes sense to repeatedly shrink and expand the node. After all, there is no guarantee that the removed data during the partial GE is the least accessed one (the satellite could intentionally remove the most accessed files first) and there is no guarantee that the new data after expansion will be more accessed than the removed data.
I think there also needs to be a setting of allocated space for each satellite - maybe I do not want to give all my free space to some satellite that pays less (or is some kind of “charity” satellite that does not pay at all), but would like to give it some space.
Thanks all for sharing all your awesome ideas with us here and please keep doing that. SNO Growth team will review them soon as a Partial GE is one of our major items for Q4 according to our 2020 Roadmap, which is actually publicly available via this link:
https://storjlabs.aha.io/published/bc0db77dc0580bb10c0faf2b383d0529?page=4
This feature seems to have been forgotten. But I do think it is an important one so I’ve turned it into a voting one in case many people want to support it (I hope it’s alright, change it back otherwise ^^)
I would really like this to be a thing, as right now shrinking nodes to reclaim space is simply not realistically possible.
I’m sure many SNOs would be happy to keep sharing space, just a little less if they need some space back. Unfortunately, right now their only option is to kill their whole node (potentially many TB), which is a shame for them and for the network.
As the number of nodes grows and as they keep filling up, this use case is going to be more and more frequent I reckon.
Did this ever get added to the code base?
It is hard to tell as nothing comes up on a google search and due to their age past links to the 2020 Roadmap are now not valid as the development process has moved to different tools.
It hasn’t been implemented. And last time I checked it wasn’t currently on the roadmap either. If you want them to implement this, make sure you vote for this suggestion at the top.
I just voted and I hope some other will do too.
Now that we are several years into the Storj project, having the possibility to reduce the storage used by Storj without having to exit completely the networks should be considered a requirement.
In the past 6 months, I had multiple times the need to reclaim some storage and thought a few times about just stopping my node completely and reclaim all the space.
I found ways around it, because I believe that decentralized storage is a great solution, but it needs more flexibility for the SNO.