Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!uunet!ns-mx!iowasp.physics.uiowa.edu!maverick.ksu.ksu.edu!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!npd.novell.com!newsun!keith From: keith@ca.excelan.com (Keith Brown) Newsgroups: comp.sys.novell Subject: Re: NFS Support in NetWare Message-ID: <1991Mar7.074317.26918@novell.com> Date: 7 Mar 91 13:26:31 GMT Sender: news@novell.com ( Lines: 59 The News Manager) Nntp-Posting-Host: ca Reply-To: keith@ca.excelan.com (Keith Brown) Organization: Novell, Inc. San Jose, California References: <1991Feb27.210937.3761@novell.com> Date: Thu, 7 Mar 1991 07:43:17 GMT In article tb@Materna.DE (Torsten Beyer) writes: >Put a slow CPU (read 68020/68030) in a box add >a really fast I/O subsystem and you get a heck of an NFS-Server. > I couldn't have put it better myself. Thank You! >And I realy doubt your 400 NFS-ops/sec numbers. When it comes to writing NFS >gets real slooow. Unless you do tricky things like the Legato ppl, or >violate the NFS protocol you HAVE to do synchronous disk-writes. And that's a >real mess. As I've said, we can optionally violate the NFS protocol and do asynchronous writes. If you choose to do synchronous writes you do of course lose out on write performance. In general, I think its fair to say that we owe a great deal of our performance to the availability of a nice big disk cache. As for the 400 ops/sec number, check us out. You will only see numbers like these on high end platforms however. If you don't want to see numbers like these, there are some good ways of crippling us. First, make sure you've only got an 8 bit LAN adaptor in the server (such as the NE1000). This nails us big time! You can imagine the problems caused by having a SparcStation pounding you with 8K datagrams when you've only got an 8 bit wide bus to squeeze all that data through. On Ethernet, 8K datagrams are fired out of Sparcstations in 5 1518 byte packets + 1 968 byte packet (if my memory isn't failing me) making up the defecit. The packets come a little over a millisecond apart and getting 'em all into memory in the time given is very hard for an 8 bit board to do. Lose one of 'em, and you just blew the whole 8K! If you must use an 8 bit card, we recommend mounting with the "rsize" and "wsize" options pulling the datagram size down to 4K or less. Secondly, make sure we don't have much memory to play with. We insist on 5 megabytes in the manual but you can squeeze us into 4. There goes our nice big disk cache! > >Add me to that list :-). Concerning Turbo-whatsoever file acces. Do you >really think this is a problem for a server with enough Memory (= cache)?. What problem? Turbo file allocation tables are things that NetWare brings into play when files get very large. A Turbo FAT is an in core map of wherabouts the pieces of a specific file live on the disk. Access to the tail end of large files is thus speeded a little as NetWare doesn't have to chase along the general purpose FAT chain to find where the end bits of the file are. UNIX on the other hand actually slows down a little when files get very large. This is because it may have to bring in more indirect blocks from the disk in order to locate the tail end of a file, the worst case being triple indirection where UNIX would have to fetch 3 blocks full of daddr_ts in order to get at the block it was actually trying to find. If I were to try and list the NetWare OSs advantages over UNIX in providing NFS file service, this point would probably be right at the very bottom of the list under the heading "Obscure Ones" :-) Keith - Keith Brown Phone: (408) 473 8308 Novell San Jose Development Centre Fax: (408) 433 0775 2180 Fortune Dr, San Jose, California 95131 Net: keith@novell.COM