OSNews

> so how is this different from Samba?

I've read a bit about it, and as far as the administrator is concerned, it is quite different. The service is managed in totally different ways, and it affects OpenSolaris systems in different ways.

Basically it is managed with existing generic opensolaris tools and is compatible and inter-operates with existing opensolaris systems. So you use a "share" command with a couple options to share your ZFS file system. That configuration might even be portable with the zfs pool... I haven't been able to nail that down yet.

This stuff is really new so there isn't much documentation or discussion out there. As of today:

A preliminary draft of System Administration Guide: Windows Interoperability for the Solaris OS will be available in the near future on the Solaris CIFS server project page at OpenSolaris.org (available soon)

Yes, ZFS supports the 'sharesmb' option. So you can say 'zfs set sharesmb=name=FOO pool/my/filesystem' and have the filesystem shared as 'FOO' under windows. This is basically the same as the 'sharenfs' property today, and can be inherited within the ZFS filesystem hierarchy.

What are the advantages/differences of sun's CIFS implementation over Samba ?

One difference is that it is in kernel. Samba is all userland. The blog post above promises better integration with the rest of the OS and I would expect it to be faster once it matures (or now, who knows).

Now, why the NYT picked up on this, I have no idea.

Yes, the Samba package is purely userspace, but it requires native kernel support at the VFS and FS levels.

Additionally, it's unclear that an in-kernel implementation of a network filesystem and transfer protocol is a great idea in the long-run. The trend these days tends to be toward pushing unnecessary functionality into userspace.



It's an IDG thing. There are probably contractual obligations. Media collusion is a Good Thing(TM)...

Notice that all three sentences in the second paragraph end with "Sun said". Outstanding journalism...

NFS is and has been in-kernel in almost every OS its been implemented on. In-kernel network file systems is certainly not a new thing.

> Samba is all userland.

Not all.
CIFS is all kernellang.

Blog comment:

Hi Alan,

Of course, as you well know (because we've spoken to Sun and asked for this many, many times in the past) that all of the advantages of being "a first-class citizen of the Solaris operating system" could also trivially be available to Samba, and I hope that you'll expose the user-space API's in order to allow us to take advantage of them.

Linux has already done this - exposing the file lease API for oplocks, inotify for change notify etc. Solaris could expand on this by giving us access to atomic NT-ACL create, NTFS stream support, the ability to push SID credentials into the system from winbindd and attach to a process etc. We already support case-insensitive filesystems of course.

In fact you could have helped us put these things trivially into Samba, and thus shared the implementation burden, rather than re-inventing everything and pushing a rather large and dangerous protocol into your kernel - something I think you might come to regret later on.

I'm looking forward to seeing the docs for all the user-space API's that will allow Samba to take advantage of these cool new features in Solaris - in fact if you want to work with us on adding this code into Samba I'd be happy to help.

Cheers,

Jeremy Allison,
Samba Team.

Essentially, Linux exposes richer APIs that allow Samba to implement a much more seamless SMB/CIFS experience on Linux than on Solaris. The functional problem isn't that Samba is limited so much as that Samba on Solaris is limited. The business problem is that Samba is too close to Red Hat and IBM.

Is that really an issue? Jeremy Allison works for Google, who is close to Sun. If anything, I'd suspect that Jeremy's aggressive GPL support may be more of a concern, no? I realize userspace licensing is irrelevant to the kernel licensing, but I always felt that Jeremy's near-immediate transition to v3 following his "dramatic" departure from Novell might cause hiccups in support from commercial organizations, given samba's ubiquitousness in servers and network appliances.

Anyways, not looking for a licensing debate, I'm just not sure I see the competitive concern with RH and IBM?

Is that really an issue? Jeremy Allison works for Google, who is close to Sun. If anything, I'd suspect that Jeremy's aggressive GPL support may be more of a concern, no? I realize userspace licensing is irrelevant to the kernel licensing, but I always felt that Jeremy's near-immediate transition to v3 following his "dramatic" departure from Novell might cause hiccups in support from commercial organizations, given samba's ubiquitousness in servers and network appliances.

Anyways, not looking for a licensing debate, I'm just not sure I see the competitive concern with RH and IBM?

I don't really know, and while I am tempted to not let that get in the way of some good opining (this being the internet and all), I'll show restraint.

However, to me, this move does make sense in the specific context of Sun's Fishworks, which seems kind of amorphous so far but (as far as I can tell) seems to be a project to make Solaris "as good" a NAS platform as NetApp's Data ONTAP. ONTAP, of course, does pretty much all of its NAS protocols in kernel. Of course that does not mean it is the best or only way, but it is one reasonable way.

Fishworks predates the famous lawsuit by quite a bit but couldn't have helped the two companies' relations. I for one would be thrilled to see something that has many NetApp qualities but conveniently omits the ridiculous pricing and IBM mainframe style proprietary-ness.

I think you're absolutely right on the money.

My first reaction to this was to ask why they just didn't add code to samba, and then to speculated that they only did this to avoid using GPL code.

After reading you're post it only makes sense for them to add CIF support so they can position Solaris to be used in a network appliance context. First they have ZFS which is designed to manage large disk arrays, and now they add CIF to the list of network filesystem protocols Solaris supports. This just allows them to integrate CIF more closely with their current offerings by just having an API to call rather then a different program.

Ideological Silicon Valley is a small place. The worst of enemies are frequently seen leaving the club arm-in-arm. The super-complex IBM/Sun relationship is the premier example.

I don't think that licensing is an issue here. Sun isn't anti-GPL. They use it whenever they want the Linux community to adopt their technology (OpenJDK), and they don't use it when they don't want the Linux community to adopt their technology but want to avoid this perception (ZFS and DTrace). They couldn't care less how Samba is licensed because it isn't their technology.

Which brings me to the underlying issue here, which is Sun's NIH syndrome. If they wanted to work with Samba to reach feature parity with Linux, the Samba team would probably propose that Sun closely replicate the APIs they use on Linux. Sun doesn't want a third-party userspace project dictating their core kernel architecture, and understandably so.

If their kernel isn't providing the necessary hooks for such projects to meet customer requirements, then they need to bring the responsibility for these requirements in-house. This was a simple matter of deciding that developing a homegrown solution on their own terms was preferable to the compromising their design to fully leverage existing free software projects.

It is, like everything in software development, a trade-off. I think that the key will be the relative degrees of success of the two projects in reaching the ultimate goal of Active Directory Domain Controller functionality. Now it's a race between Sun and Samba/Linux to provide a fully-capable *nix server solution optimized for Microsoft environments.

The licencing issue would have less to do with Sun than it does with companies they do business with. In the case of Sun, they have a licencing and technology sharing agreement with Microsoft. Part of that agreement might have required Sun to implement the CIFS/SMD protocol (and Microsoft changes) under a non-GPL licence.

At the end of the day, I assume that 8 months worth of talking, they've come to the conclusion that inclusion into the base system is a good move. Btw, lets remember that IIRC it uses a large amount of code from Apple's down CIFS implementation, so it isn't going to cause problems, as the letter someone quoted in the earlier post.

Could this have anything to do with Patent claim avoidance? Or are they just taking a different approach; one that affords more far reaching compatibility gains?

What I am not so sure about here, though, is whether this is a good idea. Is in-kernel CIFS by adding hundreds of thousands of lines of code to the kernel worth the risk? My first instinct is no, but I guess we have to wait and see.

It's worth noting that not all of the CIFS code lives in the kernel. The performance sensitive pieces and those need to interact directly with the underlying FS is in the kernel, while the annoying complicated parts (MLRPC, identity mapping, etc) is implemented in userland with door calls between the two.

What I am not so sure about here, though, is whether this is a good idea. Is in-kernel CIFS by adding hundreds of thousands of lines of code to the kernel worth the risk? My first instinct is no, but I guess we have to wait and see.

It's worth noting that not all of the CIFS code lives in the kernel. The performance sensitive pieces and those need to interact directly with the underlying FS is in the kernel, while the annoying complicated parts (MLRPC, identity mapping, etc) is implemented in userland with door calls between the two.

You are right. A reading comprehension slip up on my part.

I am amazed a developer like Jeremy would pretty much troll Sun's workers' blogs like that. Afterall, what a business does with it's own damned money is, of course, it's own damned business.

Let's get real about this. People using Solaris, and every one I have ever known, has been using Samba for Windows file and print sharing, even if they've compiled and installed it themselves.

What Sun are doing is simply going on their own merry little way of making things just as hard for people using Solaris by not reusing existing work. This will have repercussions in terms of replicating all the associated technology around CIFS, and that's something Samba is already doing. Yer, Sun: The company that gets open source development!

> Yer, Sun: The company that gets open source development!


Samba is designed by dissembling the CIFS protocol - you can never use that product knowing that Microsoft could sue you.

Sun is using published CIFS specs and relying on their settlement with MS and also MS opening up protocols per the EU settlement - that IMHO is a cleaner solution.

Plus, anything in kernel space works 1000x faster and better than user space. If you think user space is good for filesystems I dare you to trust putting your datacenter on userspace ZFS developed for Linux

Edited 2007-11-21 19:09

Samba is designed by dissembling the CIFS protocol - you can never use that product knowing that Microsoft could sue you.

On the contrary. That's what protects Samba in a whole lot of ways. If someone can say "Oh, you're adhering to this so you are subject to this agreement" then that's different.

Sun is using published CIFS specs and relying on their settlement with MS and also MS opening up protocols per the EU settlement - that IMHO is a cleaner solution.

Samba has always been the cleaner solution because they've had to understand how it all works from scratch. There's a lot of layers of crap in windows networking. I'm also not aware of MS opening any protocols that have anything but onerous licensing.

Plus, anything in kernel space works 1000x faster and better than user space

As Jeremy Allison said, Linux has the right kernel APIs for Samba to use. Also, saying that kernel space is faster than user space is extremely simplistic.

If you think user space is good for filesystems I dare you to trust putting your datacenter on userspace ZFS developed for Linux

Well, I'm not going to, am I? Not until Sun comes up with a compatible license, or relinquishes its patents that makes an implementation in Linux possible.

Not everyone is willing to accept the GPL just to save a few grand, especially when the intent is to make many more grand. Were Samba a MIT codebase, the bits which the Solaris codebase could use would be nice for Sun, but since Sun intends to integrate the code into their kernel, it's not possible. The choice is between using Samba and being forced to GPL their kernel, or making their own CIFS implementation and keeping their kernel the way they want it.

Since Sun chose not to GPL Solaris already, it's easy to see a reason for their not selecting integrating Samba into their kernel.

Sun likes integrated solutions in it's products, Samba doesn't do that - a part of this is it's portability, a part of that is it's userland basis, and a part of that is it's licence. C'est la vie.

Were Samba a MIT codebase, the bits which the Solaris codebase could use would be nice for Sun, but since Sun intends to integrate the code into their kernel, it's not possible.

You have heard of userspace and kernelspace separation, right, as Jeremy Allison has talked about getting APIs into Solaris' kernel for Samba?

Sun likes integrated solutions in it's products

I'm trying to contain my laughter as I read that, but I can't.

It doesn't matter what I've heard of, the fact is Jeremy has nothing to do with what Sun is actually doing. The integrated CIFS implementation is what Sun is doing, they like cramming shit into their kernel, that's their call. You don't get a say in the matter.

There might be one very nice advantage from implementing SMB/Cifs in the way that Sun does, that is by not using Samba, with this advantage being SMB/Cifs single sign-on in a pure Unix environment, which is not possible with Samba (v.3.0.xx), since it requires a Windows Kerberos KDC as found as part of Microsoft's Active Directory to function.

What on Earth do you think Samba is doing now? I fail to see how reproducing that work is going to help. Oh, and if you've got Unix on the server and Unix on the client then there are umpteen better ways you can implement single sign-on than using Windows technology, without Windows even being involved.

I know this is true, but if you deploy a Unix based server setup with mixed clients (Unix/Linux + Windows), single sign-on in respect to Samba 3 based SMB/Cifs is not possible!

I agree that there are better ways to implement a single sign-on environment in a true Unix/Linux, however, this leaves out SMB/Cifs on Windows clients, which is a shame ... And that might change with Sun's efforts to bring SMB/Cifs to Solaris and Open Solaris, whether or not this somewhat redundant work might seem odd to many.

Btw, I guess a lot of people would argue that had an effort like this provided e.g. Linux with better SMB/Cifs support, it'd be worth it every step of the way ...

I know this is true, but if you deploy a Unix based server setup with mixed clients (Unix/Linux + Windows), single sign-on in respect to Samba 3 based SMB/Cifs is not possible!

Why would this not be possible if you're running Unix based servers running Samba?

Samba 3 doesn't do true gssapi but instead it uses a sort of pass through method of authentication based on the server being bound to an Active Directory domain controller for Kerberos to work. Because of this, a Unix only ticket based setup will not work for Samba.

Yes, NFS and many other filesystems are in the kernel. But this is Solaris we're talking about; it already has SSL and a Web cache (NL7C) in the kernel.