Is it possible to disable receiving TTL data per node configuration?
This feature will be requested as soon as the deletion phase of the test data will start and people start whining…
TTL data is part of the Storj network, so if you don’t want this data you should just gracefully exit.
7 Likes
Thanks @Ambifacient. Marked it as solution.
(this thread was created to be on the safe side to cover the questions of the near future)
Every single upload needs both sides to agree. So I don’t see why there should be no options for SNOs to filter uploads.
Storj might not want to implement this but it’s open source so anyone can do.
3 Likes
How about using my own node software built from scratch?
You can reject the TTL uploads. The success tracker will stop selecting your node after a short time. That is almost the same outcome as calling graceful exit.
4 Likes
But graceful exit is a one way ticket while any kind of traffic filter can be adjusted or disabled.
For now TTL seems to be not much used aside the test. So I just identfied the ip ranges used and set them to lowest priority in my firewall.
Does it revisit underperforming nodes later? For example, I have connection latency issues under load on one of my nodes; eventually I’ll fix them — is that node forever branded crappy or will its reputation with success tracker recover?
1 Like
From what i have seen it takes less than a minute to recover.
It will recover and that should take only minutes.
3 Likes
Hi all,
I’d like to reopen the discussion on the topic of Disabling TTL Data, and re-evaluate the request to allow SNOs the choice to opt out of TTL data. Over the past few months, we’ve observed the impact of TTL on node operations, and it’s evident that this feature can have significant implications, see When will “Uncollected Garbage” be deleted?. It seems fair that SNOs should have the option to decide whether to accept TTL data.
The concern is that, under current conditions, accepting TTL data may not be in the best interest of SNOs. I’d prefer to gradually accumulate more data over time rather than have my nodes quickly filled with TTL, which turns in unpaid uncollected garbage that doesn’t get cleared properly with BFs. Currently, with my nodes filled with uncollected garbage, I’m unable to accumulate new, paid data, which wasn’t an issue before the influx of TTL data.
While I understand Storj’s need for nodes to handle TTL data, it’s essential that this feature functions reliably and ensures proper cleanup. Until this stability is achieved, providing SNOs with the option to decline TTL data would be a reasonable and beneficial measure. This would help maintain a healthy balance and efficiency within the network.
P.S. Suggesting a graceful exit (GE) from SL isn’t a viable option, as it’s irreversible and doesn’t address the presence of TTL data on other satellites.
In short, can we consider implementing a way for SNOs to (temporarily) opt out of accepting TTL data on our nodes until the cleanup issues are fully resolved?
Thank you for considering this request.
if you discard test TTL data remember that you will have only real customer data and after last eu1 cleaning this is a very small data. I have 40 months old nodes with 3/4tb of real data (20/18tb disks). You can check yourself on Th3Van earnings: http://www.th3van.dk/storj-earnings/2024-07-All-servers-earnings.txt
2 Likes
Doesn’t make any sense to implement this. The node is designed to store and provide the uploaded data, independently of is it TTL or not, it’s paid as any other data.
It will not be implemented.
The only way is to GE from the Saltlake satellite, if you do not want money.
2 Likes
Thank you for your feedback! I appreciate the quick response and the clarification. However, I believe the current situation might warrant a closer look. While I understand that the node is designed to store and manage all data, including TTL, and that this data is paid like any other, the issue is not with the payment per se. The problem is that the presence of a large amount of uncollected garbage is filling up the nodes, preventing us from storing additional data.
My concern is not about rejecting income; in fact, it’s quite the opposite. The current scenario is limiting our ability to maximize earnings because the nodes are being filled with data that isn’t being properly managed or cleared, which directly impacts our capacity for new, paid data.
I’m not trying to nag or be difficult, but I genuinely believe that this issue could be handled with more nuance. Dismissing the potential for an opt-out option without fully considering the implications feels like a missed opportunity to address a real concern within the community. Perhaps a more flexible approach could be considered, at least temporarily, until the TTL data handling is more stable.
Thank you again for considering these points, and I hope we can explore solutions that benefit both Storj and the SNOs.
Then I would prefer to fix the problem with the uncollected garbage instead. This is much more useful. The TTL data is a normal customers’ behavior and it should be handled accordingly.
The uncollected garbage problem may be a virtual problem, because the reports from the satellites are irregular and could be incorrect, because the tally took much more time than before. So, we preferably should fix this problem. Because the BrightSilence’s script is based on these reports and the reports from the local databases to calculate a so called “Uncollected garbage”, where both values could be (and they are) are incorrect.
So, I would suggest to fix the underlaying issues instead.
5 Likes
Thank you @Alexey, I agree! I also prefer this issue to be fixed instead. But if the solution takes a long time to materialize, this would be a temporary relief.
Both requires the developers’ time. And I’m not sure that implementing a new feature would take less time than a bug fixing… And I (as a Senior QA in the past) prefer the bug fixing.
1 Like
LOL, I (as a senior developer) have to say I don’t entirely agree 
. Analyzing, reproducing, and debugging can sometimes feel like finding a needle in a haystack and can take a lot of time. On the other hand, with well-architected code, sometimes adding a feature can be a breeze to implement. But hey, I appreciate your perspective! 
I’m a senior developer too (well, I was almost on any role in IT 
for the last 30+ years), this, of course, affects my decisions. But in this case I really believe, that we need to fix these issues to move on further.
2 Likes