Ryussi MoSMB – High performance SMB

I am back in the Silicon Valley as a Storage Field Day 12 delegate.

One of the early presenters was Ryussi, who was sharing a proprietary SMB server implementation of Linux and Unix systems. The first thing which comes to my mind was why not SAMBA? It’s free; It works; It has the 25 years maturity. But my experience with SAMBA, even in the present 4.x, does have its quirks and challenges, especially in the performance of large file transfers.

One of my customers uses our FreeNAS box. It’s a 50TB box for computer graphics artists and a rendering engine. After running the box for about 3 months, one case escalated to us was the SMB shares couldn’t be mapped all of a sudden. All the Windows clients were running version 10. Our investigation led us to look at the performance of SMB in the SAMBA 4 of FreeNAS.

This led to other questions such as the vfs_aio_pthread, FreeBSD/FreeNAS implementation of asynchronous I/O to overcome the performance weaknesses of the POSIX AsyncIO interface. The FreeNAS forum is flooded with sightings of missing SMB service that during large file transfer. Without getting too deep into the SMB performance issue, we decided to set the “Server Minimum Protocol” and “Server Maximum Protocol” to be SMB 2.1. The FreeNAS box at the customer has been stable now for the past 5 months.

Coming back to this Storage Field Day event, Ryussi is new to me. I have never heard of them and this MoSMB product of theirs intrigued me. It has been a while since a technology company decides to develop a non-open source product in a world where open source mindset reigns, especially when it comes to file sharing. In my world, SAMBA is free, NFS is free and most customers would expect things to be free too. At this moment, I was reminded of CoRAID  and their AoE protocol attempt in Linux some years back. Granted that AoE was not mainstream, can the licensed Ryuusi MoSMB approach with a well-defined protocol like SMB work in Linux, or even in FreeBSD?

What can MoSMB do better in multi-threading its services compared to SAMBA? Can it handle SMB3 multi-channel better than SAMBA? In its product site, it has listed ODX (offloaded data transfer), SMB Direct (for compatible RDMA-capable NICs), NDIS offloads, and SMB Multi-Channel sessions as strong performance features (see below).

There are other strong features such as support for Witness Protocol, and HA, giving support for enterprise applications such as MS SQL and MSCS. In recent years, we have also seen Microsoft giving more attention to the development of the SMB protocol, and this is important to change the reality that the SMB protocol is really still a high latency, low throughput protocol.

I posted the question of why Ryussi would want to come up with a proprietary SMB stack when stuff like SAMBA are all over the open source world. Their CTO, Sunu Engineer (cool name by the way!), responded that the SAMBA stack wasn’t really cut out to address some of the more demanding workload and availability. As I mentioned above, Microsoft has been putting some heavy attention since SMB 2.x, and it is just great.

SAMBA still has some way to go to become an enterprise-grade network file share system. It will always be chasing Microsoft’s new development of the SMB protocol as it continues to reverse engineer its way to get SMB working well.

So this MoSMB (pronounced mo sam bee) would have a place in this world. Lightweight, Hyper-V ready and more, it’s time for them to go BIG!