I can agree that vetting could be considered as test for SNO too, but the intention was to lose as little customers’ data as possible during the initial time of storagenode setup and stabilization. So maybe both.
However I disagree with the idea that it’s a test for SNO only. The same SNO could make a good setup and a bad setup, and perhaps the bad setup could be discovered only at scale or during attempt to repeat it somewhere with different hardware or software or OS.
As I said in an original topic, running multiple nodes on the same HDD is violation of Node Operator Terms & Conditions, so it should not be a target setup.
And this is for a reason - using the one disk for multiple nodes increases risk to wear out it faster, because it’s a mechanical drive and it doesn’t work well when multiple processes try to put a lot of stress on it, like mentioned filewalker. So, the customers’ data for these nodes at a higher risk to be lost.
Such nodes with high probability will affect each other when they receive multiple requests, thus they could loose the race for pieces more often, or even denial such requests and the customer should retry the request, loosing the speed and bandwidth.
Perhaps both reasons could be mitigated using the SSD, except losing data of several nodes at once.
However, as I mentioned in the original thread