This post was taken out of context by @Alexey
It does not make sense without the context, better to just ignore it.
Cheers guys for your input!
I don’t do this for the money, but I get your profitability arguments. I don’t believe STORJ to be something that is feasible to beginn with. I like to discuss tech stuff with you guys, learn new things, and brush up on my English
I wanted to set it up with Docker to finally have an excuse to look into it. Now I will use @fmoledina version and look into systemd and NFS mounts
Sure, instead of getting the basics right as a company, we will just outsource that task to @arrogantrabbit /s
See? This is why I love this forum! STORJ is so transparent and honest, you always get a new season of “How can I have strange priorities as a company”. It is so interesting to watch!
Will do! Are we talking about monthly looking at the dashboard or some kind of software? Because the former should be sufficient, in my opinion.
Wow! That looks bad That makes me wonder if it even makes sense to setup a node for testing. Only reason I currently see to setup a node, is to offer @BrightSilence data so he can correct his calculator again or I can at least warn other users to not trust it.
That one is easy: Max ingress TB / month. Was overoptimistic the last time I looked at it, will be overoptimistic looking back 6 months from now. You assume 700GB monthly ingress, while @Pentium100 has 0.
storagenode doesn’t support network filesystems, only iSCSI is working. If even it could initially start to work, it will stop sooner or later, see Topics tagged nfs and this is documented
Basics are done. Anyone can run a node in a documented way. If you want to have an extended or non-standard - sure, either provide a solution for the custom setup as a valuable Community member or wait until it become a mainstream. This is how the Open Source works.
I assume this because different file locking semantics make it not suitable for sqlite? Because otherwise, reading and writing blob data shall work just fine. In which case, one can keep databases locally, and storage on the NFS mount: NFS is the only network filesystem where most of the work is done in the kernel on the client, and therefore it’s the closest thing to native local disk after iscsi.
But I guess if one has a NFS server around – just running the node right on it instead would be much better solution.
Yes, the file locking difference would also affect a storage too, as reported by many SNOs and the filewalker and Garbage Collector will take forever, it also has a great latency and losing races. Some reported files loss or corruption and reducing audit and suspension scores.
unfortunately not, especially in hybrid environments (NFS server Linux/Client Windows and vice versa and so forth).
iSCSI provides a block device, not a filesystem, thus everything works as expected (but maybe a little bit slower and not so resilience as a local storage).
The biggest benefit of iSCSI over a networked file system is that the OS can usually assume it is the exclusive owner of this storage, and hence (1) can cache aggressively, (2) can assume locks are not shared over network.
However, if you can configure a networked file system the same way, it will actually be better than iSCSI—as a file system-level communication is more concise than block storage. NFS or SMB cannot be fully configured this way, but there are solutions that can. To state the obvious: Storj cannot assume responsibility for misconfiguration of networked storage and as such, discourages this kind of setup.
No, this is a completely false statement. You either don’t understand what you’re talking about, or you’re deliberately lying.
As can be clearly seen from the graphs given by him, the Pentium100 also have about 700 GB of incoming traffic per month: slightly more than 2 megabits/second averaged over a long period equals to ~700GB/Month.
I observe approximately the same levels of ingress on my nodes too: about 700 GB(~650 GB in September and looks like it will be about ~800-850 GB in October if the rest of month keeps flow at current rate) per month for 1 unique IP address. I run 3 nodes, but on same IP address so ingress is split up between them as if it just one large node.
So this value in the @BrightSilence calculator is correct and as close as possible to what has been observed in practice on the Storj network in recent months.
Close to zero was a completely different variable - the net growth rate of the volume of stored data on particular node. This is because Pentium100 has a very old and large(>20 TB) node, which has almost reached the point where the speed of deleting old no longer needed files/pieces is almost equal to getting new ones in ingress. Both of them for his case are in the region of 700 GB/month, so net grow approaching zero.
But for a new node (after vetting is done) without old files to delete net data grow rate is close to ~700 GB/Month in first month currently and will slowly decrease as it becomes older and larger. All this is also already taken into account in the calculator.
Sorry for that, but your post with setup and configuration troubleshooting was off topic in the original thread. The link is persist for whom is interested here at the top and in the original thread to this one.
No worries! It is just strange to read it without context and I can’t delete the whole thread.
During a search this thread came up again and I wanted to not confuse other users.
That makes me wonder if it even makes sense to setup a node for testing. Only reason I currently see to setup a node, is to offer @BrightSilence data so he can correct his calculator again or I can at least warn other users to not trust it.
