lwio – the SMB redirector: Building the integrated Linux SMB client experience
One of the more painful things about using Linux as a client in a Windows corporate intranet is the clunkiness of integration. The most basic requirement is that you be able to bring up the Nautilus or your favorite graphical file browser and browse through files that live on a Windows (Samba) file server. I’ll reiterate: this is one of the most basic requirements.
Now most affficianados will be up in arms when I say this. Of course, Linux does this and Ubuntu does this out of the box. But here is the rub: Ubuntu’s Nautilus file browser will does this fine. But now I want to go to my bash command shell and I want it to also be able to browse to my Windows file shares. This does not happen out of the box.
Now even if you get all of the pieces to work, the credentials are messed up. The single-sign-on experience needs to immediately transfer itself to all client applications. Even though you can sign in with your AD credentials, if I have to re-enter my credentials, it adds to the clunkiness of the experience.
Introducing the SMB redirector in lwio.
Our SMB redirector driver provides all of the semantics necessary for a file client API. The obvious next step was to pick up FUSE and begin work on a FUSE driver that would call our lwio APIs – NtCreateFile, NtReadFile, NtWriteFile, NtClose. Once you provide a FUSE driver to our SMB client, automatically, a client can mount smb shares without reentering his/her credentials. Once the client mounts a share, he can browse the directory space, copy files, move files, create directories, delete files and perform every UNIX file system operation against the SMB volume. Even better, Nautilus and the Gnome shell work without any additional work.
We’ve started construction of this FUSE driver and its is amazing how fast we’re putting together the pieces. Our Posix Virtual File System (which is the most complete lwio driver) is proxying for the SMB Redirector File System (we’ve implemented enough for the named pipe interface and its missing some of the QueryInfo and SetInfo semantics)
Now here is the even more interesting part: FUSE driver run as a daemon themselves, so a client (like the shell) has to communicate to the FUSE daemon which in turn communicates to the lwio daemon. That’s a transition of 2 processes which means at least 4 context switches to service a call. But lwio can implement a FUSE driver as another lwio driver. Just like the SMB server driver calls the IO Manager to route requests to the Posix Virtual File System, the FUSE lwio driver calls the IO Manager to route requests to the SMB Redirector File System. This implies we reduce the number of context switches between processes to half what we would have if we ran FUSE independently as a separate daemon. This was Brian Koropoff’s epiphany over the weekend. We’re still going to do this first as a separate daemon, iron out the end-to-end scenario, but then placing it into the lwio kernel is a natural optimization.
Well, I thought we’d be doing three key scenarios by April 15th. It looks like we’re going to go for a fourth scenario.
Thanks for reading!
I’ve been using smbnetfs to do this for about a year now, but it’s a bit flaky and I have to restart it every few days. It also uses FUSE, with libsmbclient, to provide redirectory/network neighborhood sorts of capabilities.
Linux’s in-kernel cifs feels a lot more solid though, so I use that for our servers, but it’s a pain to set up.
Looking forward to getting this type of ability as part of the “total package” in likewise!