Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!math.fu-berlin.de!uniol!unido!materna!elwood!tb From: tb@Materna.DE (Torsten Beyer) Newsgroups: comp.sys.novell Subject: Re: NFS Support in NetWare Message-ID: Date: 8 Mar 91 07:48:09 GMT References: <1991Mar7.074317.26918@novell.com> Sender: root@Materna.DE Lines: 46 Keith, >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. Ok, but this big cache can as well be found in UNIX File-Servers (like SUNs). >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 Don't misunderstand me. Although I'm a UNIX fan, I'm not blind. And I really see the potential your product has. On the other hand, since I have quite some NFS experience, I know it's not that easy to really get 400 NFSops out of a server unless you really know what you're doing. So, I certainly don't want to see slow numbers out of a Novell-Server. And I'll certainly will give your product a thorough look and next weeks CeBIT show here in Germany. Concerning your "violation" of the NFS reads, I really think this problem is essential. Usually when my NFS server goes down, I know all my data is save (either in my local cache, or on my server's disk). This is certainly not the case with asynchronous NFS writes. Don't you think this is a high price for performance ? And again, a UNIX box would certainly show similar figures when turining off synchronous writes. So what I'd like to know are performance numbers with synchronous write and a typical mix (like for example those generated by this legato nfs testing software). >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 Granted, BUT usually files don't get accessed first byte, last byte, second byte, middle byte. Usually it's more or less in a sequential manner. This however means, that the overhead for fetching an indirect block to memory can be neglected, since it's done only one time. Correct me if I'm wrong at this point, but I seem to remember that these blocks get cached as well. -- Torsten Beyer e-mail : tb@Materna.DE Dr. Materna GmbH VOX : +49 231 5599 225 Vosskuhle 37 FAX : +49 231 5599 100 D-4600 Dortmund 1, West Germany