Hey everyone Brandon the Product Manager @storj here. Thanks for submitting this idea, Chris VdG has a point about the redundancy between raid and erasure coding. Our recommendation is to run one node per HD. This will actually spread your overall risk of a HD failing and losing the withholdings for that specific node ID. If you have 4 2 TB HDs then the best thing to do is run 1 node per HD and if one of those fails then at most you would only lose 25 percent of your overall held amount amongst all 4 nodes. Instead of using raid to backup one of your nodes its may be in your best interest to just allocate that extra raid space to the network and profit off of it instead.
Brandon- its a good idea but u will spend x4 resources for it... most of them will be spent for operation system, not for node operations
It's common for people to add storage to their system, and for that space to appear as a new drive letter or mount point. Because Storj is casting the widest of nets to attact SNOs, most of them aren't going to be people who configure RAID or other OS-level options to merge multiple drives into one logical block of space: so the Storj client should be able to handle more than one drive/mount/directory.
Brandon's comment on Sept 9 2019 doesn't make sense. If I had one Storj client managing 4 x 2TB, and one drive died, I still only lost 25% of the files, even if running only one Storj node on top of them. If a node can read from 3 locations but falls-on-it's-face when getting read errors from a 4th... that's a software issue and would be logged as a bug. Storj beautifully handles recovery from entire nodes disappearing from the Internet: I have confidence your node devs can prevent simple I/O errors from taking down the entire app (especially if 3 other managed storage locations are still happy and healthy).
I can understand this not being a priority. But spinning things to sound like a node couldn't easily and gracefully handle one-of-many storage locations going down is misleading. Without this feature at some point, Storj will be limiting how quickly SNOs can scale to meet demand (if interest is strong: hope for the best!)
You won't be notified about changes to this idea.