I was looking at the stats at storjstats.info, specifically this:
It looks like there is plenty of available space. Is there any need for additional storage nodes? Considering moving some HDDs from Chia farming…
2 Likes
Yes and no, if you also look current grow of the whole network is about 0.5PB/month and it is expected to rise. Officially the network is said to be growing 12%/month (which however isn’t true for last month as far as I can see). See: Storj Network Growth Plan
To speak for myself, the current state actually is that my nodes are shrinking due to some testing previous month. And that test/nonsense data is being removed over time. Nothing to worry about though, since it reached its endpoint since the day before yesterday. This might be flattering the growth number above, and also the growth of the free reported space which also is said to be increased 5PB within a month.
That said, 70PB is expected to take at maximum a year or two to be filled. But it’s expected to be much less than a year according official statements. In reality, 70PB is a reported stat: if I have a node of 5TB, I can decide to report 1TB or even 10TB. The reality probably is more nuanced: there are many node operators just adding disks over time, as soon there disks fill up.
For former Chia plotters, it might be interesting just to throw away some plots from the disks they have already running. And just start a bunch of small nodes, 1/disk. I hear many of them throwing away plots over time as soon as the nodes grow, because current RoI is much bigger on Storj. But I hope some Chia folks will pitch in here.
The reasons why not to start just a single node are plenty:
- There is a held back payment for the first 15 months. This is true for every node starting, the sooner you start the sooner you get full payment.
- If you start off those nodes at once, they compete for the ingress, meaning during those 15 months the ingress is being divided over all the nodes. So held back payments per node are low.
- Since you’re dividing the ingress over more disks, the IOPS are also divided meaning less interference with also running Chia-activities.
- If there are more nodes withing a /24-subnet (so: 255.255.255.0-part of your external address) they are being seen as one node, sharing the ingress. Meaning that you’re a bigger competitor within the subnet with more nodes, so receiving more ingress (as far as I have understood the concept, might be off on this one).
5 Likes
Thanks for the very thorough response!! Answered everything I was wondering and more. I’ll start with a small node and see if it fills up.
2 Likes
According to latest town hall a 10PB customer is supposed to on board soon, and if that’s 10PB raw data then it’s ~29PB after erasure coding.
Otherwise they (Storj) have also been shouting for more nodes in South America and I believe APAC.
3 Likes
I endorse jwvdv’s answers.
compared to chia, the storj drives fill up WAY slower. So I have used chia plots to fill in empty space on drives when I think about it.
And also the operations put a much larger strain on your storage subsystem than chia did (which was nearly zero). many operators of nodes (individual) larger than 7TB or so have started adopting things like SSD caches or metadata drives for instance.
3 Likes
many operators of nodes (individual) larger than 7TB or so have started adopting things like SSD caches or metadata drives for instance.
How is this incentivized by Storj? Will the audits suffer if the performance is too poor? Is there some latency metric etc I can monitor?
1 Like
There is a kind of latency factor, that could be monitored but hasn’t made it to the board they. That could be the success-rate seen from satellite’s perspective. Although there are folks calculating it by script from the logs, these aren’t the same for variety of reasons.
So to say it this way, Storj is still growing mature. Something that might annoy you some days, but better can be contemplated and amazed about. So actually, you don’t have any idea how your node is performing in comparison to others and what exactly can be optimized (OS, file system, concurrent processes, connection, location, …). So you’re kind of on your own, however there are many nice folks around here on the forum helping you out when trouble comes.
2 Likes
Isn’t, but many including me got a lot of uncollected garbage. Which I only managed to get rid of switching file system to ZFS with special devices for the meta data (which are essentially partitions on SSD drives).
Badger cache, of which you will find information on the forum, also helps a lot to turn these problems down.
2 Likes
It’s possible, but not confirmed yet. However, if your node would be unable to provide a stripe of the piece for audit, it can be affected.
See
keep an eye on http://www.th3van.dk/
He have 30/40 months old nodes with full history Index of /storj-earnings
No… he never filled
1 Like
I checked his stats a couple times: I don’t think I saw him over around 1.3-1.4PB filled? What has happened over the last month with all the TTL data aging-out has been tragic for him: like 2/3rds of his used-space lost. I bet he’s really hoping for that 10PB customer to start uploading 
If you like the project and want to try something different, well developed, with a strong community, future proof, go for it. Don’t expect big returns, though. If you are sirious about it, it’s better to start with one node, just to see how things work and tune the setup to be prepared if the inflow will increase.
2 Likes
I think he is on Select network, not public, may be partly on public.
So it not possible compare onions and tomato’s.
2 Likes
I know for me the problem with slowly performing node wasn’t satisfying upload/download request (those were great), it was the backend maintenance, garbage collection, and trash emptying that were starting to fail or wouldn’t finish fast enough. Which would result in:
- disk filling up and stopping the node
- nodes running out of RAM from slow disk writes and crashing
- unpaid and uncounted garbage being stuck in with live data
- trash hanging around too long before emptying
3 Likes
My feeling after following the forum over the last few months and seeing where was the focus of development is that Storj doesn’t have enough fast storage: close to biggest customers, with good latency, bandwidth and decently fast storage. This is not something you can read from summary statistics like the Graphana dashboard.
3 Likes
Thanks for all answers! Decided I believe in the project and hoping that it follows the growth trajectory, so I setup four storage nodes: one for each HDD I currently farm Chia on (allocated 2 TB to each). Will be fun to see if they fill up - it hopefully can’t be worse than the ROI for Chia at least 
3 Likes
I wouldn’t count on ROI, even if it’s possible. The usage from the customers is not predictable, so it could be empty for a long time and then - BOOM, all your bandwidth and disks are screaming.
2 Likes
I’m a node operator in the STORJ-project for over a year now, and I’m now really getting RoI. During the first six months it really felt like a hobby. Although, it still feels like it sometimes if I take the time spent to fix things up and spent in this forum into consideration.
2 Likes