Path: utzoo!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!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: <1991Mar10.041835.6883@novell.com> Date: 11 Mar 91 15:51:27 GMT Sender: news@novell.com ( Lines: 101 The News Manager) Nntp-Posting-Host: ca Reply-To: keith@ca.excelan.com (Keith Brown) Organization: Novell, Inc. San Jose, California References: <1991Mar7.074317.26918@novell.com> Date: Sun, 10 Mar 1991 04:18:35 GMT In article tb@Materna.DE (Torsten Beyer) writes: >Ok, but this big cache can as well be found in UNIX File-Servers (like SUNs). Actually, you sent me scrambling for my SunOS manuals when you pointed this one out. I believe you, but I'm having a little trouble finding out anything about how they implemented it (true dynamic disk cache allocation). Perhaps you could point me to the right place in the books (Sun ship a small deciduous forest with SunOS) and/or answer me the following questions: 1) At what point does SunOS say to itself "Hmm.. Nobody appears to be interested in using me as a proper UNIX system. Seems all they want me for is NFS serving. I guess I'll grab all this memory I've been sitting on and stuff it in the disk cache." And 2) What happens when a UNIX based (sorry, SunOS based) NFS server that has made this desision is slumbering in it's machine room at 3 O'Clock in the morning when I, heavily camoflaged as a 9 track tape drive, sneak up to its console and give it a nasty surprise by logging in and firing up the biggest make(1) its ever seen in its life? I know full well what a NetWare v3.11 servers response would be to such treatment. It would go something like "You want to do what???? Sorry, I think you have the wrong operating system, I specialise in network services. Try the UNIX pig next door. Oh, and turn the light off on your way out." > >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. This whole NetWare vs. UNIX as an NFS server debate puts me in mind of an old Python sketch which you may have seen (I am getting therapy :-). Its the one where John Cleese walks into a cheese shop to purchase some cheese, only to find out after considerable negotiation that the cheese shop doesn't in fact have any. The similarity ends if you consider NetWare v3.11 as the cheese shop. We have plenty of cheese. How much would you like? By comparison, UNIX is a supermarket. It also has cheese but its going to take you alot longer to find it among all the other goods they stock and it almost certainly won't have as much. The manager of the supermarket (the UNIX kernel) is also unlikely to know as much about cheese as the manager of the cheese shop (NetWare v3.11). Anyway, enough "market speak"...... >And I'll certainly will >give your product a thorough look and next weeks CeBIT show here in Germany. And I'll certainly be pleased to show it to you. I'm at the mercy of our German office regarding the equipment I'll have but hopefully they'll provide me with something meaty enough to make it impressive. If I arrive to find two 16Mhz 386SX systems containing 8 bit Western Digi cards and a stack of diskettes containing a certain "popular" brand of PC UNIX, there is liable to be blood :-) > >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? In my situation, no! I'm not monitoring a nuclear reactor, niether am I scanning the skies over Iraq looking for incoming scuds. If I was I'd turn write through back on. I'm comfortable in the knowledge that my NetWare NFS server is doing its damndest to flush my data to disk every three seconds if it can. Besides, in my experiance, my client is far more likely to crash than my server. Then where's all my valuable data? >(like for example those generated by this legato nfs testing software). The very software we used (with some limited support for being able to run nhfsstone across multiple clients added. A single SparcStation isn't nearly man enough to saturate NetWare NFS running on high end server platforms). I doubt I'll be allowed to publish results of our internal testing as we obviously don't want to cheese off any hardware vendors. However, I expect we'll get benchmarked many times by independent interested parties so I dare say it doesn't matter. > >Correct me if I'm wrong at >this point, but I seem to remember that these blocks get cached as well. > Your not wrong, indirect blocks are cached by UNIX like any others. So, to obtain one useful block of data, you just used 4 blocks out of the disk cache. I believe we just proved that the UNIX disk cache has the potential of only being one quarter as effective as NetWare v3.11s. In reality of course, its effectiveness will be a larger fraction of ours than a quarter (the cached indirect blocks hold pointers to other disk blocks applications might decide they need). I can't however think of a situation where UNIXs disk cache will be more effective than ours. Oh, to be fair, Turbo FATs obviously use memory too, but it is of course memory well spent :-) 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