Native SMB/CIFS through ZFS or Samba Instead

Question

I was totally unaware of native SMB/CIFS on ZFS. This wiki doc does not mention performance differences. What kind of performance differences exist between the two?

Solution 1

In my experience the kernel mode server out performed samba with my clients. If performance is your number one concern, skip samba. That said, there are a number of limitations to the Solaris kernel-mode SMB/CIFS server, most notably:

• Only runs in the global zone. Samba can run in multiple isolated zones and/or the global zone simultaneously.
• Sharing happens at the filesystem level, not the directory level. So for new shares, zfs create pool/fs a new zfs filesystem, copy data over and share it (instead of sharing an existing directory)
• No following symlinks in shares, unless they are on the same filesystem.
• No child mounts. If you share a filesystem, sub filesystems are not shared. (e.g. two filesystems, pool/fs and pool/fs/subfs. If you share pool/fs, you won't be able to access the contents of pool/fs/subfs without sharing it separately. It'll show up as a directory via SMB, but will be inaccessible.
• None of the Domain controller/AD Master, WINS Server and other niceties of Samba

Of course doesn't do cross-protocol locking (a file locked via SMB is also locked via NFS when nbmand=on is set with the in-kernel server) and doesn't do VSS integration so snapshots show up in the Windows 'Previous Versions' tab in the properties window.

If you can live with the limitations of the kernel mode server and you don't need zone-level isolation, I think it's the way to go. If you're a heavy Linux/Samba user now and like some of it's unique features, feel free to stick with it. Also of note, if you're running SmartOS the choice has been made for you, they make it nearly impossible to run stuff in the global zone (with good reason) so you'll have to use OmniOS, OpenIndiana or Oracle Solaris if you hate Samba.

Solution 2

Another issue with the native SMB server: it won't share remote filesystems mounted via NFS. Now that may sound like a bad idea at the best of times, but it was an easy way for us to, for example, make some web development areas accessible to folks. We didn't worry about the file locking issues because the web developers were (a) mostly using Dreamweaver, which uses its own file based check in/check out methods; (b) a fairly small close-knit group; and (c) generally responsible for areas without much overlap. I can't think of more than a handful of times that developers overwrote each others files (and generally file locking wouldn't have helped).

So, finding out that the shiny new server wouldn't happily share these files was a bit of a surprise, especially because this point didn't seem really emphasized in the various sites discussing the new SMB server. Ah, well, if there's one thing I've learned about Solaris it's that: "things change". :)

And, I concur that, unless these needs are critical for your shop, the native SMB server is the way to go. It lacks the flexibility of Samba, but it does seem to "just work" once it's set up, and it does seem to have pretty good performance.

Solution 3

I don't have hard numbers, but I can say that the native smb runs in kernel space. Samba runs in user space. Although running in kernel space doesn't guarantee that it'll be faster, all other things being equal kernel space code will be faster.

I do know that the configuration and management of the in kernel smb is much easier than samba. What's the size of your user base?

Comments

[Spence]

I have a bit of a CompSci beef with this answer. Excessive context switches can impact performance. Code running in user mode vs kernel mode doesn't inherently make a difference. A block of code running in user mode that doesn't cause a lot of context switches won't really perform much differently running in kernel mode. In the context of Samba, though, it's likely that there will be a significant number of context switches (because of its fundamental nature as an I/O daemon) so you're probably right w/ respect to Samba. It's not something that's true in all scenarios, though.

[songei2f]

Thanks for the tips, @notpeter. I awarded this one because I was not really looking for a discussion about context switching and kernel versus user space. That was interesting theoretical knowledge, but not very practical.

[Andrew Henle]

One point of information: I encountered horrible performance accessing a native SMB/CIFS kernel-shared ZFS filesystem with Android devices and had to set up a separate zone just to share the filesystem via Samba to work around the performance issues. I never did determine why the kernel-mode share was so slow on Android devices as it was just too fast and easy to set up a dedicated Samba zone.