This “32GB” node size test network has highlighted an issue that many people can run 100 or more times the nodes than their system can handle. This can cause issues if too many of these large operations die due to running out of disk.
Another issue is that no one can announce that the network as a certain amount of storage available as its worse than random guessing since people can use node count to justify the monopoly “money” figure for raw capacity.
My suggestion is simple and covers the more “accidental” over provisioning done by eager beavers. And yes won’t stop people with the ability to modify the code but seriously that is a small number willing to do that.
It is simply create dummy chunks of max or expected-average chunk size and store in the record store to fill the record store directory to the expected node size. We currently have node size of 32GB which is merely an expected average size that the 128K max record node will get to. So on startup the node will fill the record store to 32GB of dummy records. Either with max chunk sized dummies or expected average sized dummies.
The code already removes chunks that the node is not responsible for and the node would remove dummies first when needed.
This solves the over provisioning issue well enough that people can confidently state what the raw capacity of the network is within a typical error margin. This is an important figure along with stored data on the network. Also allows real/actual knowledge on how full the network really is.
It’s an anti feature that needs maintaining, the empty chunks need to be prevented to enter the network and removed with priority…
What problem is this supposed to solve? Once the network fills and price rises storage will be there - the expensive resource is bandwidth - not storage space
(actually I thought about this as possible solution for a short moment too… Because without filling the space there is no way to ensure it’s there… But I think it doesn’t solve a real world issue and therefore should be avoided…)
This is the attempt to enforce others to ‘play by the rules’ nothing more… I guess it boils down to the decision if that’s worth the hassle with the assessed probability of success
Being able to actually know what the “raw” capacity of the network is.
One of the big metrics to be able to promote the network is to be able to indicate the amount of storage available across the network.
We were using “raw” capacity based on average node size (32GB for this beta net) times the number of nodes and divide by 5 for available storage. And then how full the network is based on average fullness on nodes you have.
But with over provision then these figures are now like monopoly money, worthless.
Also in addition assists in preventing cascading collapse as someone with 100,000 nodes but a few TB only having their nodes fall over due to the nodes getting just a bit fuller. EG going from a 195 records average to 200 records average (9.75TB to 10.0TB total with only 10TB disk with OS etc). Then this will have a flow on effect causing other heavily over provisioned node setups collapsing. My 60 nodes are using around 1 to 1.5Mbit/s upload & <5%CPU and 100,000 nodes is 2.5Gbit/sec, so is more than possible for those with 12 computers or more in their setups.
We won’t get to see what happens with this network though because with 140k nodes that’s 4.4PB. Even half filling it to 2.2PB will be a tall order. We’ve only ever seen a few tens of TB uploaded. If a few dozen of us all had tokens from a faucet and were uploading like crazy we’d have a chance of getting it filled to a decent level.
One for a Commnet maybe? Everyone over provision their nodes, lots of people upload like there’s no tomorrow and see what happens? Then add more non overcommited nodes and see if it can be salvaged.
Edit
Some people overcommit their nodes but not everyone!
And later in the network we won’t have those empty levels anyway… Won’t be worth running nodes below 0.5 token per month per node for me at current value and I guess it’s pretty similar for others…
So are we afraid of over provisioning in the life network or in the current test networks?
Well both, those doing over provisioning are gaming the system by getting a lot more stores paid for then they are proving hardware for.
If I had a 5Gnit/sec link I could run over 1/4 million nodes with only 20TB backing it (I’ve got 100) and be a huge portion of a young network gaining a ton of payments then end up collapsing, then running them up again.
For one its not fair to those running with honest nodes and secondly its drains the rewards that should be being spread around more. And secondly its a danger to the stability of the data and network.
If the beta can have 150K nodes after many months of beta and with over 60K in the hands of 3 or 4 people (one with over 28K) then in a live network without the incentives we might start off with 100K and grow to 300K in 6 months. But I come in with 250K nodes and holding 45% of the chunks and getting 45% of the rewards only to collapse and repeat it till I collapse again. How many chunks will be permanently lost, even with the expanded Sybil protection of 20 -25 nodes maybe holding chunks
Its a problem in a couple of dimensions.
Now if i could do that with one 5Gb/s link and my personal hardware, then some like Swiss with his hardware across the world and large drive could run 100K to 250K in each location doing this and potentially the network could collapse completely when one falls over due to no space and causes the cascading across all his way over provisioned machines.
Its unlikely he would do that, but it is not just a theory that this could be an issue but easily done and consequences real
I kind of agree but anyone large enough will have systems in place to manage there nodes so no collapse.
Just reduced node count as space is required and should the price not be going up which will attract more node runners to get more nodes in the game?
In the long run I don’t expect it to be profitable to run on hetzners for months to month running costs so that will push us to home hardware where in most cases the router will be the bottle neck not the HD space.
Nope when there is no disk space left and the nodes end up completely shunned. Its not a instantaneous collapse but one where the nodes are shunned and other nodes churn the data to maintain at least 5 nodes responsible for the chunks of the shunned node. This maybe over the period of an hour. Remember that nodes on that machine are also getting churned chunks added speeding up their demise. Basically speeding up the collapse on that machine. But if many people are doing this then their nodes start this process of dying off.
To do this only takes knowing how to run safenode-manager or following people who show that
for ((i=0;i<100000;i++)); do safenode …; sleep 10; done
Editing the code is another higher level of understanding and represents perhaps 1 in 1000 or 1 in 100,000 of these script kiddies doing this sort of gaming
