And I finally rest my case…
You are now literally quoting text from the moved topic and still responding here… Please stop! You’re just giving @Alexey more work to do to move your posts. That discussion has moved here: 5 nodes on the same HDD vs 5 nodes on a separate disks
4 Likes
Vetting process… should be better if it is different for newbies than veterans?
For ex., you should be marked as a veteran if you have 3 nodes active and all are older than 6 months. When you start new nodes, the vetting should be faster, because you already know what you are doing, you know how to manage them and you are interested in long term comitment. So the new nodes you start should be trustworthy.
veeting process is mostly for hardware, because here is lot of old hdds, and it just give time to understand that hdd work stable without loosing big ammount of data.
2 Likes
Please read more about Gateway MT here - specifically this section about Regions and Points of Presence where it states:
We currently have hosted Gateways in several regional locations and expect to expand as needed. The Gateway endpoint https://gateway.storjshare.io is configured to automatically route the traffic from the instance closest to your location.
I.e. Gateway MT is a globally distributed, multi-region cloud-hosted S3-compatible gateway.
3 Likes
thank you for pointing.
1 Like
Hmm… I didn’t considered cloning. Good sugestion. I don’t know if it works for NAS disks, though. I only have Synology NAS nodes, and for cloning, I should take the disk out and perform the cloning on a PC with Windows. All disks are ext4, so I should be able to read them in windows with an extension installed. I don’t know if DSM will have a problem when wakes up on another disk…
1 Like
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.