Ladies & gentlemen, We use FAServers at our department since Feb. 1994. Since then we have had five units from model 450, F330 to F540. At one point or other our NFS clients were HP, Digital, IBM/RS6000, SGI, Convex, Apollo and even MAC (via Xinet software). Packages range from Cadence to Framemaker to other semiconductor manufacturing related simulators. We have documented uptime of over 99.7%, which includes scheduled downtime. Its truly a lights out operation. Needless to say I am a big fan of the product, to date. Yet, when a sisterly department was looking into NFS fileservers, FAServer was brushed off their short list, which included only SUN and Auspex. Even after two hours of discussion with one of the key IS member I still was in the dark on why FAServer was not even in the running.
From what little I could gather, the only sour note on FAServer
was "Network Appliance lack of industry standards"; whatever that means. My guess is that the other prominent players were pointing to the fact that FAServer file system is not "BSD or System5", their OS is not "UNIX" and so on and so forth. When I look at NetApp's brochure, there is no reference to any "standards" or their membership/affiliation to any of the scores of industry consortiums. I tried my best to get something in writing from NetApp stating their commitment on standards. Folks, I know this is absurd. But I had to do it. Anyway, NetApp conveniently ignored my request. So this is you mission, if you chose so... Please let me know if the alleged "lack of industry standards" effected your operations? If it's not against your company policy, it may help, in future, to know (a) what type of industry is this FAServer used? (b) how many FAServer and approximate total disk space? (c) which part of the world are this installed? (d) how important is standards based tools to your company and why you picked FAServer when they seems to be build on proprietary environment? (e) what is your performance and uptime experience with FAServers? (f) how critical is FAServer's uptime for your company/department's operation? (g) installed since when? (h) any experience you can share between FAServer and Auspex/SUN file servers?
Thanking you all in anticipation.
Philip Thomas Motorola - ACT, M/S M350 2200 W. Broadway M350 Mesa, AZ 85202 thomas@act.sps.mot.com rxjs80@email.sps.mot.com (602) 655-3678 (602) 655-2285 (fax)
When I look at NetApp's brochure, there is no reference to any "standards" or their membership/affiliation to any of the scores of industry consortiums. I tried my best to get something in writing from NetApp stating their commitment on standards.
I apologize, and I'll see if I can figure out what happened to your request. In the meantime, I assure you that we have a strong commitment to standards, although not to all the same ones that a general purpose vendor would.
Network protocols are the critical standards for a network appliance (i.e. any dedicated network device, such as a router or network printer). Unlike a general purpose system, we do not have to comply with standards relating to user commands, programming interfaces, or internal kernel interfaces. So you won't see us worrying about POSIX or the kernel VFS (virtual file system) interface. One of our big advantages as an appliance vendor is that our implementation is not constrained by standards internal to the system. (Cisco doesn't run BSD or System V either!)
But we absolutely track the standards relating to file service protocols. The most important standards are those for TCP/IP, NFSv2, NFSv3, HTTP, and CIFS. (We actually shipped NFSv3 before Sun did!) CIFS, the standard file service protocol for Win95 and NT, is more fluid than the others, and we have an agreement with Microsoft that gives us good access to changes that they are making.
The file service protocols are the obvious critical standards, but there are many others that we support as well, including standards for DNS, telnet, inetd, RPC, XDR, portmapper, lockd, NIS, ARP, RMT, rdate, NDMP, syslog, SMTP, etc. Most (if not all) of these have RFCs describing them. We support many of these in client-mode only, such as NIS, DNS, SMTP, etc., because our goal is not to serve these protocols, but to be a client to them in order to simplify administration. I suppose I should include networking standards too, such as Ethernet (10 and 100), FDDI, CDDI and ATM. We have Gigabit Ethernet working in the lab.
We co-developed the NDMP (Network Data Management Protocol) protocol to allow better interoperability between 3rd party backup tools, file server vendors, and tape jukebox vendors, and are working with a number of other vendors to promote this standard. (See www.ndmp.org.)
Tom, would something like this note be sufficient if it were printed on NetApp letter head? (Alternately, is the electronic note sufficient as it stands?) Please let me know...
Dave
So you won't see us worrying about POSIX or the kernel VFS (virtual file system) interface.
...nor about compatibility between the on-disk file system format of WAFL and that of the BSD file system or the System V file system or NTFS or..., if that's what the concern about the file system being "neither BSD nor System V" was. (Then again, at that level, a UNIX machine using VxFS or JFS or XFS or... isn't "BSD or System V"; the file system's on-disk format is neither that of the BSD file system nor the SV file system, although it presumably provides semantics similar to one or the other or both.)
If the semantics of the file system, *as visible from clients*, don't match those that the client expects, that's a different matter; we intend to provide compatible semantics there to the maximum extent possible (the requirements of providing both NFS and CIFS access may constrain us here, and we might not be able to match the semantics of two different flavors of UNIX with different file systems without providing an option - for example, we have an option to control whether users are allowed to give their own files away, USG UNIX-style, or are not allowed to do so, Research UNIX-style).
-
guy＠netapp.com -
hitz＠netapp.com -
Philip Thomas