Thx. iSCSI is not as bad as is has been recommended here. As long as you know what you’re doing. (not saying I do…)
The issue with any networked protocol is added latency, not throughput. What are your success rates looking like?
Either way, iSCSI is a LOT better than SMB or NFS at least.
3 Likes
I’m not a big fan of trowing block storage on a file storage problem but thats what I can do to keep micro services architecture. SMB is by far the best protocol to handle file storage in windows .
about 1100 µs in latency over iSCSI.
There is another problem. It’s working only if both client and server are Windows, otherwise you will meet a lock problem for SQLite databases (12 pcs. FYI)
I’m talking about my storage volume, not my application. why would I store my application on a share when I obviously have a system drive??
The storagenode stores its information in SQLite databases, which are part of the storage 
1 Like
ah you are correct. I have not seen any issues with CIFS, just heard about NFS. I ran my node on CIFS for 3 months or so. Not sure why filelock is such a big problem on NFS 3/4
It could be if at least CIFS server is Windows. But I think the Linux SMB client could not be compatible. The Linux SMB server usually doesn’t.
It looks like starting a lot of uploads and no one is finished.
i got my SMB on linux setup to be full compatible with windows machines… took a minor war to get it to work tho and i still have some user account stuff i need to deal with… but it works and the windows machine doesn’t have to do or change anything, it just looks like a regular windows share…
there are a few parameters that needs to be added to the samba.conf file for it to talk native with windows machines… duno exactly why it works, but it works, the user stuff is hell tho… going to be looking into a better way of controlling that.
did run into the lockfile issue, and didn’t find a way around it, but that was before … maybe ill give it a try when i get some spare time for something like that.