A customer recently asked, “Is Data ONTAP based on UNIX?” Complicated question.
The first version of Data ONTAP borrowed lots of code from Berkeley Net/2 (one of the earliest open-source releases of UNIX), including the TCP/IP stack, system boot code, and device drivers. Since then, we’ve borrowed liberally from other open-source UNIX releases. We wrote the command line interface from scratch, but we designed it to look like UNIX, since our first market was UNIX system administrators. Clearly, ONTAP is related to UNIX.
On the other hand, ONTAP’s architecture is very different from UNIX. There is no user-space, the filesystem is completely different, the RAID and diskubsystems are completely different and most important of all, the interaction between subsystems is very different. The key data paths from network to disk look nothing at all like UNIX.
You can imagine two completely different ways of building an appliance. You could start with UNIX and strip out, disable, or hide the pieces you don’t want. sOr else you could start from scratch, inventing a new architecture optimized for the task at hand, but borrowing liberally from the UNIX code-base as appropriate. We chose the latter.
Interestingly, our advanced ONTAP GX architecture is built on top of a full UNIX release. We took Data ONTAP, including WAFL and RAID, combined it with the new code from our Spinnaker acquisition, and hosted the combined result on FreeBSD in a combination of user processes and kernel modules. For security and simplicity we have disabled and hidden many parts of FreeBSD.
Even for ONTAP GX, this isn’t quite the “start with UNIX and slim it down” approach, because most of the system lives in large kernel modules that kick UNIX out of the way. They grab control of almost all of the memory, as well as the critical device drivers, and we even re-wrote the scheduler to make sure the UNIX parts don’t get in the way. We’re still not using the normal UNIX data paths.
Why the difference? One reason is that CPUs are way more powerful now than when we started, so a little bit of extra overhead matters less. (Our first product used a 50 megahertz 486.) In addition, UNIXs have gotten much better. When we started, there was no Linux, no FreeBSD, and AT&T and UC Berkeley were still in a legal battle over big chunks of the Berkeley Net/2 Release.
Although these two approaches feel very different to engineers developing the systems, each with its own advantages and disadvantages, there is little if any difference to the end-user.