Dual-Protocol File Server

Setting up a file server for Linux and Unix clients using NFS, or a Samba server for Windows clients, is something that virtually every admin can handle. But if you have to support a heterogeneous landscape of users with a single file server, you will automatically be tempted to set up shares with both NFS and Samba. On the network-side, this is no problem. The actual problems for a Janus-headed file server result from the different locking types in Windows and Linux and impending inconsistencies if clients cache data. Another difficulty: NFS and CIFS organize their access control lists differently, which previously meant that only a subset of POSIX 1003.1e ACLs and Windows ACLs remained as the smallest common denominator.

NFSv4 significantly reduced the difficulty of dual-protocol operation by more closely reflecting features of Windows filesystems, and of CIFS in particular, structurally, with mandatory locking, share reservations, and delegations. NFSv4 also transmits the user and group information as UTF-8 plain text and no longer as a numeric identifier, as in NFSv3. The idmap service then converts usernames and groups to the file-server identifiers, which makes cooperating with Samba easier.

The whole thing is standardized: RFC 3010, from December 2000, established a new ACL system that is tailored to NFSv4. For example, ZFS supports ACLs exclusively according to this standard.

Greg Banks from the Cyrus IMAP project presented the Richacls project [16] at the Ottawa Linux Symposium 2010 – an implementation of NFSv4 ACLs in the Linux kernel with advanced file masking – that superimposes a consistent file rights model on all remote filesystem protocols and accesses both servers and clients. Greg Banks's co-worker on this was Suse employee Andreas Grünbacher, who is with Red Hat today. Banks manages the active Richacls project, which includes kernel code and also patches for Samba, NFS, and XFS.

NFSv4 supports named attributes – an additional byte stream that the NFS stores along with the actual file [17]. Windows supports a similar concept called alternate datastreams for its NTFS filesystem. Named attributes, by the way, are not related to the extended attributes of the ext filesystem.

Multihosts and Zero Copy

NFSv4 shares resources via a pseudo-filesystem (virtual root filesystem) so that the admin can define arbitrary share paths. Clients mount all shares with a single mount command, which only references the NFS server. As of late, an NFSv4.1 client can also specify multiple hostnames when mounting, which promises to relieve the administrative burden of dealing with frequently changing server names.

To increase the speed, clients can establish multiple connections with the NFS server. NFS groups multiple connections in a session in what is known as session trunking [18]. There are other performance-enhancing measures in the current NFS. In case of a copy operation, the client requests the data to be copied and then copies it back to another target on the server. This method is obviously inefficient.

But with zero copy, the server itself can perform the operation, which requires only a copy-on-write copy in the simplest case. Users can create these copies manually on Btrfs and XFS systems with the cp --reflink command. The filesystems only allocate additional storage in case of writes to the copy.

Samba supports zero copy with an IOCTL. And there's a technically very charming variant of this that outsources the virtual copy action to Btrfs [19]. NFSv4.2 offers another corresponding approach, but the patches by Anna Schumaker, who works for NetApp, are still under review [20].

Conclusions

The de facto demise of Sun Microsystems has heavily affected the NFS project. On the one hand the development – at least in terms of version numbers – is progressing very slowly. It is difficult to accurately forecast whether there will ever be an NFSv5 release. On the other hand, the missing or outdated documentation slows down any user who wants to try out new features: It is difficult for any admin to know what functionality exists in the NFS implementation packaged with their choice of Linux distribution.

Although some features work seamlessly with the current kernel and the NFS-utils, admins are forced to perform extensive research for many optional features – and to gain experience with a test setup. One complicating factor is that not every Linux distribution enables all the NFS innovations in the kernel or provides the latest NFS-utils.

The specification of the current NFSv4.1 dates back to the year 2010. Although work on NFSv4.2 began as early as 2011, the corresponding specification [21] still only exists as a design today. Among other things, version 4.2 can deal more efficiently with sparse files, named attributes, and zero copy. Newer kernels already support some functions from the NFSv4.2 specification.

These welcome developments are in risk of disappearing, however, because the current home of NFS, IETF, does little to promote NFS as a potential competitor for Samba.