1.i want to shrink my nose from 20TB to 5TB
i am currently storing 0.7TB how to do that?
Node Version: v0.26.2
1.i want to shrink my nose from 20TB to 5TB
Hi! This is currently not yet possible, we need to wait for implementation of partial graceful exit. See also Reduce storage / partial graceful "exit"
Stop the storage node, remove the container and run the docker command with the adjusted value for the storage.
@heunland: he uses only 0.7 TB so far.
good point, in that case., it is still possible to reduce the total size now. My comment above is only valid in case you already stored more data than the new amount of space you want to share.
Re-awakening this thread as I’ve experienced issues with this process.
I had to shrink my StorJ reservation below the point of current utilitzation. Since than my egress traffic is super low. Like 90% less than before shrinking.
A friend of mine recently did the same, shrinked his reservation by just a few gigabytes below current utilization and egress traffic immediately went to super small percentages.
This seems to not be related to overall low network throughput, as the IPv6-only node that he is operating (but that was not shrinked) outperforms the two shrinked nodes.
Any suggestions on how to fix and/or troubleshoot?
trafic is gone, bacause stefenbenten overed big tests. Today is only client trafic, but it slowly rizing.
I had the problem for more than 2 months now, while my friends nodes out-performed me. We run on the same hardware combo, same setup, not same subnet.
Only my friends problem has occured recently and could be explained what you mention. A > 2month long stretch of small egress amounts that correlate with the storage reservation change sounds like a different problem to me.
In case this is helpful, SNO dashboard has been showing roughly -250GB disc usage since that change and against intuitive believe, reducing the reservation size has not freed up any hard disc space.
what hardware do you use? Yout setup?
As explained in other threads this was due to how the tests were performed. Mainly the tests were downloading data that was recently uploaded. So if you node was full, you did not get much egress because you didn’t get any uploads and old data was barely downloaded.
Also it has been mentioned a few times that reducing the storage reservation does not free up space because there is no option for “partial exit”. Data will only get deleted if the customer deletes it.
When will shrinking be available?
My intuitive engineering approach would that the task to free up some disc space is similar to a graceful exit.
What are recommendations for handling the situation where an operator needs to reclaim storage space consumed by StorJ in the meantime?
I don’t think this will be available anytime soon as it is a more complex problem.
I am not aware of any recommendations others than moving the data/node to a different harddrive where you have enough space.
As I’m new to the forum (and still a bit confused who’s who), is that an official StorJ statement of your personal guess @kevink ?
So if one must reclaim disk space, the way to go is to burn the current token and restart from scratch?
I would not expect any kinda shrinking to become available anytime soon the team is more focused on getting the performance up, making everything more efficient, getting rid of errors, being able to shrink a node is the least of there worries right now.
They just added graceful exit which is the only way to shrink anything is by exiting the network per satellite.
But thats only good for nodes that have been running for 6 months minimal then it will go up from there.
You can check what they plan to work in the roadmap here
Let me try to get right in between the 2 options you mention there. I can’t speak for Storj officially, but I’m also basing my response on Storj communications and not guessing.
Storj works in an agile manner. Without getting into the details of that, it basically means that there is a backlog of stuff to do and stuff is being worked on in short sprints of 2 or 3 weeks. The decision for what to work on in a sprint is made shortly before the sprint starts and work that needs to be refined for the next sprints can be done as well. This means you usually only have a good idea of what will be done in the next 2 sprints. There are broader long term milestones like the different testing phases, but those won’t contain as much detail.
Based on what has been communicated I can be fairly certain in saying partial exit is not planned in the next 2 sprints, but still resides on the project backlog. I don’t think anyone can get more detailed than that, probably not even anyone from Storj themselves.