Interview: Taking Samba beyond POSIX

Interview: Taking Samba beyond POSIX

An interview with Andrew Tridgell on his latest Samba rewrite

developerWorks [IBM] talks to Tridge about his work at IBM, the state of Samba 3.0, and his thoughts on the smbd rewrite.

Robert McMillan

April 16 2003

If you were lucky enough to attend the Samba eXPerience conference in Gottingen, Germany, you may have caught Samba creator Andrew Tridgell's talk on "Exotic Filesystem Backends".

And what exactly does Tridge have to say about exotic filesystem backends? It turns out that since being hired by IBM's Almaden Research Center in January of this year, the Australian hacker has been working on pushing Samba beyond the POSIX world and figuring out what work needs to be done to get Samba to support new filesystems such as XFS, ext3, and Storage Tank. The answer is nothing less than a complete rewrite of Samba's smbd code, which has become his latest pet project.

developerWorks: What kind of work are you doing at IBM?

Tridgell: I wasn't hired as just a Samba person. In fact, I joined the Almaden Research Labs, which are looking a bit further out than just a product around the corner. My job description isn't just Samba stuff, although at the moment the particular research project that I'm working on is a network-attached storage project, where we're looking at next-generation NAS solutions and integrating that with some of the exotic filesystems that IBM's developing. It's quite interesting work, and it gives me the opportunity to do work that's a bit longer term. While I was at Quantum and at VA [Tridgell's two previous employers --ed.], I was constantly running across limitations in the core structure of Samba. In order to ship products on a three- or four-month type time scale, we really just had to have workarounds for those core limitations, and it meant we had to have some poor compromises, particularly in the area of NT Access Control Lists [ACLs] and lack of support for things like file streams, or some compromises in the area of user and group management. They were just pragmatic compromises, because we didn't have the luxury to really say, "Well, let's rewrite all of Samba."

In a research organization I can take the longer view, and I can look at exactly what needs to be done over the next year or two, and say, "Where do we want to go with the next-generation version of Samba?" and "What should it look like if we want to solve these problems properly?". I can put serious effort into solving those problems. In fact, a lot of the work I'm doing now was inspired by the problems that I hit while developing products for VA and Quantum. So eventually, other companies that make NAS products are going to benefit from this work.

dW: Are you talking about Samba 4.0 type problems?

Tridgell: Tentatively, it's probably going into 4.0. It might go into 3.1 or 3.5. It really depends how it goes. It's really early days in this work. I've spent probably a month or so on the core rewrite so far. It doesn't compile yet. It's a long way from compiling. I'm hoping that by the time the Samba XP conference comes around in Germany, that these core changes will, in fact, be compiling and I'll be able to start getting other developers to look at them. Thus far, all I've done is started the core structural changes. I've shown those off within the Samba team, and got approval from other core developers of Samba to say that they like the ideas. Thus far everyone's very enthusiastic about them.

dW: Can you tell me more about what these changes will be?

Tridgell: Samba has historically been a gateway to POSIX. It has provided access to POSIX-like systems. That's been extremely useful, because a lot of people have POSIX-like systems on their servers -- like Linux and Solaris and AIX and other systems -- and it's extremely useful to provide good-quality CIFS [Common Internet File System] access to those POSIX servers. But POSIX is rather limiting in some areas. There are some things that are extremely hard to map from the Windows world to the POSIX world. A good example of this is a thing called file streams. In the Windows world, a file can have multiple sets of data associated with it. Whereas in the POSIX world, a file has a single data stream associated with it. You can number the bytes in the file from 0 to N, whereas a two-dimensional-type access is possible in Windows.

Now, we've got away with not supporting filestreams in Samba for quite a long time, basically because nearly all applications on Windows do support a server that doesn't have filestreams, because the old-style Windows servers, like Windows 9x don't support filestreams. And so applications have tended to support systems with and without filestreams. Microsoft Office stores its files a little bit differently on a Samba server from how it stores itself on a Windows 2000 server. But that's going to change over time. I wouldn't be surprised if future versions of Office started requiring filestreams, for example. I wouldn't be surprised if more applications started relying on a feature like that.

So we need to be able to break the tight link to POSIX and be able to support, directly in Samba, the more advanced filesystems that are now available on Linux, such as JFS and XFS. There are a whole bunch of interesting filesystems that are being developed for Linux, and those have capabilities well beyond what is defined in the core filesystem POSIX specification. We'd like to be able to take advantage of those within Samba.

dW: So what filesystems are you looking at in particular?

Tridgell: The Storage Tank filesystem is the one that I'm looking at in particular, which is a SAN-based filesystem.

But the initial work I'm doing at the moment isn't Storage Tank-specific. It's far more general work. The first filesystem backend I'm targeting is an extremely unusual one: it's a CIFS backend. So you'll have a Samba server, which talks to another SMB [Server Message Block] server -- such as another Samba or Windows server -- and the core of Samba actually uses remote file access to another SMB server as its backend. It's not that we're ever expecting anyone to ever do this in a production system. It's very hard to imagine situations where you want to have this sort of CIFS-on-CIFS gateway, but the CIFS backend does provide an ideal test bed for developing the core functionality of exotic filesystem backends in Samba, because a Windows 2000 backend has all of the features we could ever possibly want, because it has all of the features that CIFS supports, because it is CIFS. So it, for example, supports native NT ACLs, because it is native NT.

So by using that as an experimental filesystem backend in Samba, we can develop the core structures needed to support all of these extensions. Once this has been put onto slightly less exotic filesystems like ext3, XFS, or Storage Tank, then they will have a subset of the functionality available, but we'll know that the core structures are functioning correctly. We'll have a perfect backend, if you like.

dW: Microsoft has talked about making some fundamental changes to its filesystem -- creating a database-oriented filesystem such as the Object File System, for example. If Microsoft completely changes its filesystem, do you expect the Samba project to evolve to support this?

Tridgell: As a sort of subtitle to the Samba project, we've hoped that eventually Samba will go away because it won't be needed. But that's tongue-in-cheek, really. There's been the possibility of Microsoft switching to a different network filesystem protocol for quite a long time. For example, some people thought that maybe WebDAV was going to be it, and the Web was going to be the filesystem. That seems to have died as a possibility; it just doesn't have the richness of functionality that Microsoft applications want.

I haven't really been involved in discussions on this database alternative to filesystems. It appears to be extremely speculative at this stage. I wouldn't be surprised if at some stage Microsoft does change their core filesystem protocols, just because they're carrying a lot of legacy baggage with the CIFS/SMB protocol. There's an awful lot of stuff in there that just doesn't make sense with modern platforms, but has to be carried forward because it's part of the core protocol that they've inherited, both from themselves and from others. So starting with a clean slate must be very tempting, but then again, it would be a huge engineering effort for them to do this. And we haven't seen any signs that this is imminent. But then again, maybe we wouldn't see them. We're not exactly at the top of the CC list for that sort of discussion inside Microsoft.

dW: Do you think that some of the research you're working on will have applications beyond CIFS?

Tridgell: Samba is already itself spreading a little bit beyond CIFS. People are installing components of Samba when they don't want file and print serving at all. We're seeing companies installing, for example, just the Winbind daemon, which is a newer component of Samba that provides domain integration -- allowing your Linux desktops to integrate with existing Microsoft domains without offering any file or print services at all. And that's a growing use of Samba. So, in fact, Samba's role is already growing beyond just file and print.

If a new protocol came along, would the Samba team start working on it? Well, that really depends on how closely related the protocol is to our existing work and whether it's appropriate for us to work on it. For example, when Active Directory came along, Active Directory is very closely tied to the existing MS-RPC protocols and the existing domain infrastructure. So it was clearly something that the Samba team could tackle, and we've tackled it over the last 18 months or so, and things are working very, very nicely.

But Microsoft has also got a hand in the NFSv4 pie, and NFSv4 is something that, although it shares many concepts with CIFS and SMB, it doesn't share enough technical detail for there to be any common code, so the Samba team isn't involved in that in any way, except as an interested bystander.

dW: You were saying that you learned a lot of things working on NAS projects in the last couple of years. What are the big problems that you're looking at solving with Samba?

Tridgell: The general problem that Samba is trying to solve is a semantic mapping problem. It's trying to map the semantics of POSIX onto the CIFS protocol. And so Samba consists of a whole lot of little components that provide that mapping. The classic example is mapping from case-sensitive to case-insensitive. Windows expects a case-insensitive server, whereas POSIX systems are traditionally case-sensitive.

Now it would seem fairly trivial to map from case-sensitive to case-insensitive, but in fact it's hard to do it efficiently. It's very, very hard, given a file name, to prove the file doesn't exist. If the file does exist, then you can have a pretty good guess as to what its case-sensitive name might be. And in fact, most of the time it'll just be that exact string that was sent over the wire from the client. But proving, absolutely, that a file doesn't exist in any case combination is quite expensive on POSIX. Now POSIX systems don't have any hooks to say, "Please do this open in a case-insensitive fashion," and so we've had all sorts of infrastructure in Samba to provide for mapping from case-sensitive to case-insensitive. But that infrastructure has been embedded deep in the code of Samba, all over the place.

These days we're actually starting to see filesystems appear on Linux and on other UNIXes with the ability to have non-POSIX semantics. They might, for example, have some method of asking the filesystem, "Please operate in a case-insensitive fashion." And we need to teach Samba that it doesn't need to do all this work now, because the filesystem is going to do it -- and vastly more efficiently than Samba could possibly do it in userspace. But excising all that code from Samba is a fairly major job. So I realized that, in order to do that, we needed to restructure Samba into a far more modular structure that allowed backends that were completely divorced from POSIX to be used without paying the penalty of the POSIX mappings. That's really the core of the rewrite that I'm attempting at the moment.

dW: This sounds like a whole new architecture for Samba.

Tridgell: It is a significant change. It's only changing the core smbd functions, really. It's not changing, for example, the domain functionality in the MS-RPC code, it's not changing our user- and group-mapping code. So it is only affecting what has always been the core piece of Samba, but it is perhaps now, I'd guess off the top of my head, maybe 30 percent of the code in Samba. On that 30 percent of code, though, it's a quite significant rewrite.

dW: I also wanted to ask you what's the latest with Samba 3.0. It's been in alpha since November of 2001, I think.

Tridgell: It's been in alpha for a very, very long time. In fact, alpha is, in some ways, a poor name for it, because it's actually being used in production in a number of companies. At least two vendors that I know of are shipping it in production code in their appliances. It's being fairly widely deployed. We were hoping that we'd get the final release done by the Samba XP conference this year, but we didn't get it done. There's still some documentation and a bit of QA that needs doing, but the state of the code is really quite good. For some purposes, it's considerably better than our stable releases, because it's had an awful lot of QA from these companies that are using it in production. In particular, when I was at Quantum, they had a very good QA department, and that team put a lot of effort into stabilizing the 3.0 code base as a file server. Particularly on extremely large domains, or under very high load. That work means that Samba 3.0 is, in fact, rather more stable than one might expect for alpha code.

dW: So those are the circumstances -- large domains and high workloads -- where people would be most interested in Samba 3.0?

Tridgell: Yes. Or, for example, if you needed Active Directory support. There are a lot of companies that need Active Directory, because their infrastructure is based around the Active Directory model. 3.0 is your only choice in that case. It's the only one that supports Kerberos authentication and supports LDAP with an Active Directory server -- that type of thing. Plus, it's a much more flexible authentication system. If you need a sophisticated authentication backend, you really need Samba 3.0, and for internationalization 3.0 has vastly better character set handling. It now talks Unicode over the wire to Microsoft clients rather than using the multi-byte encodings. That allows it to support non-ASCII character sets in a much, much cleaner, better way.

dW: Where does 3.0 really act like alpha code, then? Who would not want to use it?

Tridgell: The documentation still isn't really complete. The management tools are still a bit rough. There are a few things like that, that are not quite done. If I was doing the releases, probably, I would have already released it as 3.0. I used to do releases much, much faster when I was the release manager a few years ago. Each release manager tends to have their own style... Jeremy [Allison] was the most recent release manager, and Jerry [Carter] has just taken over from him a few months ago. And Jerry and Jeremy tend to be a little bit more conservative, which is probably a good thing.