Yeah, I agree, under assumption that is consistent with Storj recommendations that you use JBOD it should work. It might be a little more difficult within proprietary NAS systems. Synology apparently doesn’t use anything that wouldn’t be readable using a standard Linux system, which is a great feature of them, but even then there might be some features that would not be preserved by a simple disk clone.
I installed all my NASes as RAID type Basic, and ext4 file system. I don’t know what JBOD or Basic means. Other option was SHR.
JBOD means «Just Bunch Of Disks», i.e. no attempt to join them into a single volume whatsoever. Just several separate disks, each not requiring any other drive to present its data. A cursory look at Synology’s documentation suggests this is what they call the Basic level, though you should probably ask someone with actual experience with Synology to explain how it works.
I’d avoid using the term. JBOD is often used to refer to joining disks into a single volume in a dumb sequential way. So similar to RAID 0, but without striping and it works with HDD’s of different sizes. Since JBOD can mean both, and Storj recommends against the latter, I would just say use separate HDD’s to avoid the confusion.
Synology is actually a good example. Offering both basic and JBOD. Basic is separate volumes per disk, JBOD combines them into a single sequential (spanned) volume. Don’t use JBOD on Synology.
3 Likes
Well no, that’s how you should be able to do it, but linking my GitHub never seemed to work for me. And you’ll also notice my GitHub uses a different pic. I also never got the GitHub contributor title despite having contributed to the code.
The way I did it comes with an interesting story. I actually exploited a bug in discourse that has since been closed. It’s a fun read here: Custom avatars on forum
But don’t get your hopes up, I didn’t describe the method and @pac reported the bug responsibly to discourse so they could fix it.
2 Likes
I thought it is under preferences?
It was briefly enabled, but I believe the option for custom was removed to prevent impersonation of Storj staff.
Lets not drift off into this topic now. Time to get back to the Storj economic model. I’m surprised there was barely any response to the quotes from the twitter space I posted here: Let's talk about the elephant in the room: The Storj economic model (node operator payout model) - #270
Probably because all the speculation that we were able to post has already been posted, and the quotes, nor the Twitter space as a whole, gave us any actually new information to work with.
The specific mention of the possible change in egress payout stood out to me especially.
Because 70% of my payout is from engress, as anyone elses with not full nodes, this will affect us, obviously, but I hope is not a dramathic reduction. I’m just starting to make some money after 2 years 
I am interested in the % of the Storj payouts that it is still subsidized by Storj Labs Inc.
You can simply look at data stored on eu1, us1 and ap1 and compare it to data stored on other satellites. Ultimately, I think it’s irrelevant. We’re looking for a future sustainable system, so we should assume no to minimal test data in that scenario. Currently it’s still a lot. But unit economics should not factor that in. It’s not fair to have customers or node operators pay for test data in any way.
1 Like
I Agree. But we cannot ignore the fact that it’s been 4 years since the launch of Storj v3. Any future sustainable system design should take into account the % of the current payout subsidized by Storj Labs Inc. SNO Payouts with actual customer income should be a good starting point.
Well that just shortness their runway. We’re gonna have to assume that will be insignificant in the future. Hopefully by the time their reserves run out. I’d rather focus on what the future situation should look like rather than trying to find out when it should be implemented as that could change a lot with fluctuating STORJ value. So for ease of discussion I’m gonna assume test data will be mostly gone at that point.
on repear work i forgot expansion factor so 10$ for tb to sno egress + 20$ for tb to Hetzner x 2.78 = 65.6$ for 1 tb Repear work, i thin this process will kill Storj Laps much faster then 20$ for today Egress to SNO
That is not correct. When 28 pieces are lost, the repair worker needs to download 29 pieces and upload 28. So it’s pretty much 1 to 1. The expansion factor does not apply.
Thank you for pointing, its my lack of knowledge’s.
1 Like
After all it is hard even to think about investments to Storj infrastructure without knowing how it would be, that’s why I hope Storj Lab will not lasting this situation for long, as at this ingress rates existing storage will end soon.
But that’s just hypothetical. We don’t know (yet) what Storj will come up with.
Right. Currently you don’t know if you should invest or shut down your nodes.