Integrating Windows NT and UNIX systems together is pretty easy until the problem of sharing NFS-mounted filesystems arises. Windows NT, 95, and 98 simply are not designed to handle NFS mounts. The Windows operating systems can share their own drives between themselves, but third-party software is usually required to handle UNIX-based NFS drives.

To help simplify the problem of sharing NFS drives, NFS gateway products have been developed. These gateway products typically run on a Windows NT server and make the NFS mounted filesystems look to other Windows machines on the network as if they were Windows-compatible filesystem. This way, a Windows 95 machine can access a UNIX-based NFS filesystem through the Network Neighborhood window. The NFS gateway software on the NT server handles any conversion issues for the client.

Three of the best-known NFS gateway products for Windows NT are Hummingbird’s NFS Maestro, FTP’s InterDrive Server and WRQ’s Reflection NFS Gateway. To evaluate these gateways we configured three identical Windows NT 4.0 Server systems with the respective gateway products, then connected the three servers into a Fast Ethernet network with two SCO OpenServer and one SCO UnixWare servers, two Solaris 2.5 servers, and one HP-UX 10.2 server, all with NFS-shared filesystems. We configured each NFS gateway product to recognize the six shared filesystems, and tried file accesses back and forth from twelve Windows 95 and Windows 98 clients. All three NFS gateway products performed better with NT Service Pack 3 installed. If you don’t have this Service Pack on your system, it can be obtained from Microsoft’s sites.

A number of design criteria are important for a solid NFS gateway product. First the NFS engine that handles UNIX to Windows compatibility must be fast, capable, and flexible. Ideally, the latest version of NFS, NFS 3, will be supported along with the older standards. Non-UNIX NFS mounted filesystems should be supported as long as they conform to the NFS standards. Support for NIS (YP) is necessary in many cases to allow sharing of NFS resources. Configuration and management of NFS mounts from the Windows NT server should be fast and simple. Mapping NFS drives to Windows network neighborhood drives should be easy, and permissions for each mount should be customizable to prevent network-wide access and potential abuse. Some added features of several gateway products are APIs to allow programmers to incorporate NFS gateway commands into applications, as well as extensions that allow configuration of NFS filesystems from the Windows NT server.

Reflection NFS Gateway, FTP InterDrive Server and NFS Maestro install easily with wizards. These installation routines require little from the installer other than to accept or override directory defaults. A reboot is necessary to activate the gateway server software. None of the installations tool more than ten minutes, most of which was spent reading data from the CD-ROM.

To a client machine, UNIX NFS mounts appear as server drives. For example, mounting an OpenServer /usr directory as drive M on the NT server will make that drive appear on all Windows 95 client machines as part of the NT server’s native drives. Mapping that drive to a local drive letter on the client machine makes pass-through from the UNIX to Windows client transparent. The NFS gateway software will not run on a Windows 95 system.

Using an NFS gateway product on Windows NT is slightly different than using a product like SCO’s VisionFS, which allows Windows clients to see UNIX directories. Since VisionFS isn’t a full NFS implementation it does have some limitations. (On the other hand, VisionFS has the advantage that it is fast and easy to install and configure.) Since VisionFS is really limited to particular platforms, installations with heterogenous UNIX hardware platforms will find true NFS a better choice.

Hardware Requirements

All three tested NFS gateway products have much the same software and hardware requirements. They all use Windows NT 4.0 Server and work best with SP3 installed, as mentioned previously. All three products were tested under a beta version of Windows NT 5.0 and worked well there, too, although we did all the performance testing on NT 4.0 Server systems.

Hardware requirements are a fast processor (a Pentium is recommended although all three will run on an 80486), and basic NT system requirements. A minimum system would have 16MB RAM but in reality a working NT Server system will have much more. We tested with 64MB and 128MB and found no difference in performance even with moderate loads on the servers. Disk space requirements are moderate, ranging from a couple of megabytes to about 5MB. All installations are done as Administrator.

WRQ Reflection NFS Gateway

Reflection NFS Gateway provides for all the features we expect from an NFS gateway package with a friendly management interface. An API for both NFS and rpc is included for application integration. The only hitch in installation will occur for current Reflection users who have an NFS client on their system. To install the Reflection NFS Gateway software the NFS client must be removed. Since there’s no facility to remove only the single component from a Reflection install, we had to completely remove Reflection X from our NT server, install Reflection NFS Gateway, then reinstall Reflection X. WRQ should be able to come up with a better solution than this. For non-Reflection users, there is no problem installing Reflection NFS Gateway.

Reflection NFS Gateway uses windowing to great effect, offering administrators a simple and clean NFS management tool for the entire network, regardless of where the NFS mounts are located. From a single machine, mounts on other NT Servers can be managed, which is a handy feature for larger network administrators. Mapping new NFS drives is remarkably simple, requiring only the path to the exported filesystem. Also from a single location an administrator can map NT user accounts to UNIX user accounts. A "Match Users" option lets you assign NT accounts to users who already have UNIX accounts, and vice versa, saving a fair bit of typing for administrators.

WRQ builds a bunch of handy utilities into Reflection NFS Gateway. A statistics module allows you to see current NFS mounts, browse NIS domains, and modify NFS file and directory attributes. Real-time examination of NFS mount usage lets you see where bottlenecks occur. The event logger built into the package is much more useful than NT’s default event logger as it shows protocol-level activity.

Hummingbird NFS Maestro Gateway

NFS Maestro Gateway is part of Hummingbird’s lineup of UNIX integration tools competing head-to-head with WRQ’s Reflection series. Although many of the components do the same tasks (X server, NFS gateway, and so on) the implementation methods are quite different. NFS Maestro Gateway has all the features you would expect from an NFS gateway, including remote administration (using a set of Java tools) which can be loaded from the server to the clients.

The NFS Maestro Gateway interface is simple to use, requiring only a few windows to add and setup mounts. Each mount can be individually tweaked for performance and throughput, which WRQ’s Reflection product does not allow. A handy feature is the ability to replicate the automatic filesystem mounting files UNIX offers (such as OpenServer’s /etc/default/filesys). This allows for redundancy and fail-over mounting in the NT server to be configured, although it does require a little experimentation and knowledge on the administrator’s part.

NIS integration is good. NFS Maestro Gateway allows mapping of UNIX user account to NT accounts, although the ability to merge user account lists of the two operating systems together is missing. Statistics generated by the NFS Maestro Gateway utilities are good, but not quite as elaborate as those that are in the WRQ product. Having said that, the NFS Maestro Gateway stats are probably all an administrator will need.

NFS Maestro Gateway includes a parameter-tuning wizard that can determine the best way to configure the software for NFS usage. Although the default settings (both a low and high block transfer can be used immediately), administrators will find the thirty minutes the tuning software takes to run worth the effort. We found a small but appreciable performance benefit after letting NFS Maestro Gateway tune itself. This requires almost complete control of the NT server for the testing time, but the process is almost completely hands-off.

FTP InterDrive Server

The FTP InterDrive Server uses a single clean administration window to control all aspects of the package. Configuring the mounts was as easy as the other three packages. The addition of LPD services from the same window made network printing accessible to all Windows clients. Several options from the main window allow for status messages to be displayed at any time showing the current NFS mount usage, any failures, and the load imposed by users. A proprietary system seems to be at work with InterDrive Server that allows exporting more quickly than either WRQ or Hummingbird products, as the performance section of this article shows. InterDrive Server does not come with any documentation, but there is on-line help that will guide you through the package.

InterDrive Server integrates with the Windows NT ACL system to allow mapping of UNIX and NT users. While not quite as slick as the approach in WRQ’s product it does work well. A feature system administrators will love is the ability to set the InterDrive Server’s priority, bumping it high when NFS access is critical for users, or lowering it when they are occasional events. This prevents wasted NT server CPU cycles and can help optimize the server for better overall performance.

A neat and useful addition to the InterDrive package is WebNFS, which is FTP’s method of delivering files to Web clients over the network (or an intranet). Files are tagged as being public within the system and when so tagged can be accessed by WebNFS. The end result is that for files that need to be readily available to entire networks, faster file transfers are possible and some administration overhead is relieved.

How we tested

Assessing the NFS gateway products against each other showed that the three are remarkably capable and similar. The Reflection NFS Gateway software’s interface was more complex than that of NFS Maestro Gateway, with the latter looking a little dated and minimalistic by comparison. FTP’s InterDrive Server was in the middle, not quite as fancy or elegant as the WRQ product, but better than Hummingbird’s. If anything, FTP’s interface was the slightly better blend of power and simplicity. NFS Maestro Gateway did have the nifty performance tuning capability that the other two products lack, while FTP’s InterDrive Server let you modify the priority of the NFS software, a real boon on many systems.

Remote administration of all three products worked perfectly, and there’s little to chose between them. The reporting from Reflection NFS Gateway is better than the other two, although more complex to assimilate. The Java-based clients of NFS Maestro Gateway seemed faster and a little easier to work with than Reflection’s administration tools. Again, though, little to chose between the three products.

Setting up the mounts and configuring access for NT network users was equally easy with all three packages. The ability to fine tune the NFS Maestro Gateway mounts was handy when using a separate, heavily loaded network to one Solaris machine. The automatic configuration routine in NFS Maestro Gateway ended up giving us about a ten percent performance improvement over the un-tuned system. Head to head in servicing client usage of mounts (scripted and running on twelve clients simultaneously) showed only a three percent performance difference in responses between the Hummingbird and WRQ products, with NFS Maestro Gateway slightly faster. This is essentially insignificant for most networks, and results could vary depending on the nature of the networks.

The speed demon of the three was FTP’s InterDrive Server. We’re not sure if it’s the proprietary method they use for mounts and partitions or simply better software design (probably the former), but the system outperformed both Hummingbird and WRQ products by about 12 percent. Clients found mounts faster and file transfers were consistently quicker. We tested all three products using both NFS v2 and NFS v3 and there was virtually no difference in the overall results.

What about reliability? During a hectic three days or continual testing and another two weeks of more casual use, not one of the three gateway products caused a system crash. They are all as reliable as you can expect NT software to be, and even when we tried to force crashes the systems regained their footing admirably.

So how do you choose between the three NFS gateway products? In terms of performance, usability, interface, and capabilities, the three products are all excellent with none standing out as significantly better. Reflection NFS Gateway reports and windows are slightly better than the other two, as is the NIS support, but NFS Maestro Gateway has better performance tuning capabilities and remote administration. FTP’s InterDrive Server is faster in just about every respect and the administration interface allows pirority adjustments.

Choosing between the three as the single product we would buy for our network is difficult. Pricing could be one issue, depending on your local retailer. On pure performance issues alone, choose FTP’s InterDrive Server. For tuning abilities alone, choose Hummingbird NFS Maestro Gateway. For the best interface and reports, choose WRQ’s Reflection NFS Gateway. Even better, roll a dice. There’s no Top of the World between these three, as they all reside in that lofty position. You won’t compromise with any of them.