No. There are 2 cpu in 2 different pc.
Bandwidh is the culprit.
One intel jxxxx something with 2cores4threads often loaded 40%
One R9 9600x with 12cores 24threads. Sometimes 9% /2full threads loaded.
This is already congesting my 100er line/Lan. So i guess i have to limit the nodes bandwidh even more with the 50er line.
Let me speak from my heart 
I am absolutely against of implementing some kind of raid0\MergeFS (so any system without redundancy- this topic was merged and renamed not by me)
what i suggest is to add value like that in configuration:
instead of single storage.path= d:\nodestorage path (or sda1)
implement
us1.storage.path= d:\us1 storage path (or sda1)
eu1.storage.path= e:\eu1 storage path (or sda2)
ap1.storage.path= f:\eu1 storage path (or sda3)
saltlake.storage.path= g:\saltlake1 storage path (or sda4)
trash.storage.path= h:\trash storage path (or sda5)
when we are talking about resources it will save us (sno) 1/2-4/5 of memory and cpu amount (depends on hdds connected):
lets say i have 5 hdds: 20tb, 12tb, 8tb, 6tb and 2tb
failing of 1 physical drive will less affect the redundancy (in that kind configuration it has 20% to fail the trash drive) and for 4 other drives data (customers data) will be safe and consistent
also it will allow sno to move date from one drive to another in more convenient and granular way, choosing drives that are better fit for that kind of satellite and dividing iops between drives
I am not a big data architect so i could be wrongā¦
I see, yes, in this case the increase of the bandwidth if possible could increase the throughput. I hope your
would survive.
So, even more points of failureā¦
You may do so by the way, at least for docker nodes or symlinks may work. However, you may end like this:
Just because
In summary - the node checks availability, writeability and readability only in the storage subfolder (or the folder where all blobs, trash, etc. are located).
If you would use junctions/symlinks/docker mount for every satellite to the own HDD, the node will not detect, that one of the āsubfoldersā are now disconnected. As a result - the blazing fast disqualification (several hours).
So, the current solution for this weird request is to spin-up 4 nodes, each has trusted only the one satellite with an own HDD. I clearly do not understand why you need it like this, but well. Itās possible right now without risking to be disqualified when your symlinks are going down.
1 Like
using junctions/symlinks/raid0 is absolutely unreliable- totally agree with this statement
thatās why i am talking about hardcoded feature (maybe not now, in some distant future) that will allow expand nodes in a safe way
i am sure- no one will use unreliable features if we have choice (now its expand node with possibility to loose it or install new one with vetting period)
I do not see any reason, why we need to spend time of developers to re-invent a wheel.
You may do it right now with a complicated or unreliable setup, and itās uncommon. Then do it and take all consequences, if you are really need it.
Perhaps I do not understand the basic restrictions for your setup.
There is lots of research done into filesystems and storage, for at least the last 80 years. There are lots of existing systems for storage that are tested, debugged, improved by large teams of people who know what they are doing and have the resources to do it.
Adding any kind of ad-hoc RAID mergefs or what-not directly into the storj server is basically asking to divert the Storj team to reimplement (in a suboptimal way) something that is already better handled by outside hardware and software. I think it is extremely misguided and definitely hope they never even consider it.
I personally appreciate that the way Storj handles data is to point it at one folder and thatās it. This way you can implement any kind of backend you like.
1 Like
Its going strong, dbs on usbstick, orders on os ssd.
Additional external fan.
1 Like