dyer@spdcc.COM (Steve Dyer) (02/26/91)
In article <1991Feb21.234900.11916@novell.com> keith@ca.excelan.com (Keith Brown) writes: >NetWare doesn't carry with it all the additional baggage that >makes UNIX such a great interactive OS. NetWare does no swapping and >paging to disk, it does not have to set up and tear down virtual >machine environments for service processes, no unnecessary internal >buffer copies are required to copy data between user and kernel space >(Everything is kernel space in in NetWare OSs, consequently NetWare NFS >transmits data directly from the disk cache to the network on client >reads and shifts data directly from LSL (network) buffers to the disk >cache on writes) While I am willing to suspend my disbelief (until I try it) that a Netware NFS server might be superior to a UNIX NFS server, a lot of what you say is a red herring. Now, attempting to compare oranges to tangelos, if you've got a UNIX machine dedicated as NFS server (the analog of a Novell file server--remember, one of these is not going to run 123 at the same time), mostly running nfsd processes, there's no swapping or paging involved, except to handle whatever extraneous non-NFS activity there might be (and this presumably would be controlled by the sysmgr.) Nfsd processes have their own context but run in the kernel's address space. In other words, "everything is in kernel space" on a UNIX NFS server, too. That is, one which is based on the Sun reference kernel implementation (read: almost every single one.) I mean, many of your arguments for the superiority of Novell over UNIX strike me as more marketspeak than tech speak. We might as well claim that a UNIX NFS server is superior to a Novell server because it doesn't have the "additional baggage" of dealing with DOS and Mac files. Which might sound good but the statement is pretty content-free. -- Steve Dyer dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer dyer@arktouros.mit.edu, dyer@hstbme.mit.edu
rbraun@spdcc.COM (Rich Braun) (02/28/91)
keith@ca.excelan.com (Keith Brown) writes: >>NetWare doesn't carry with it all the additional baggage that >>makes UNIX such a great interactive OS. NetWare does no swapping and >>paging to disk,... dyer@spdcc.COM (Steve Dyer) writes: >While I am willing to suspend my disbelief (until I try it) that a >Netware NFS server might be superior to a UNIX NFS server, a lot of what >you say is a red herring. There was also an earlier statement to the effect that a Novell server with the Novell NFS NLM was the 'cheapest' way to get a high-performance high-capacity NFS server onto your TCP/IP LAN. It's not only not the cheapest, it's also quite deficient. How many Unix people are going to like the filenaming limitations imposed by the DOS filesystem? (eight characters, then a dot, then three more; characters like comma and plus are restricted; etc.) My challenge was answered privately by e-mail from a Novell person who said, in effect, laugh at us later if we don't manage to rake in the bucks on this one. And also suggesting they're justified in setting the price high because Unix users have come to expect NFS server capability as standard issue, but Novell has to charge the money for NFS users because they don't think standard Netware users should have to subsidize NFS users. I forgot to mention in my earlier article that SCO, Sun, et al sell an NFS _client_ along with their _server_. Is the Novell solution also going to offer a DOS _client_ NFS package? I doubt that Novell is in that business. I'd suspect a company like Atlantix should be well-positioned to mount a serious challenge in this area. Hey Atlantix, would you like some source code for a Novell-compatible NFS server? By way of disclaimer, I'd like to point out that my company is not in the business of providing DOS or Unix network solutions to its customers; I'm merely an interested user and observer. -rich
rbraun@spdcc.COM (Rich Braun) (03/01/91)
I'm curious: for a customer who is getting 3.11 Netware from Novell, when it comes out, what is the additional cost increment to get the NFS NLM? -rich
billbr@xstor.com (Bill Brothers) (03/01/91)
In article <6614@spdcc.SPDCC.COM> dyer@spdcc.COM (Steve Dyer) writes: >In article <1991Feb21.234900.11916@novell.com> keith@ca.excelan.com (Keith Brown) writes: ] ]While I am willing to suspend my disbelief (until I try it) that a ]Netware NFS server might be superior to a UNIX NFS server, a lot of what ]you say is a red herring. ] ] ]I mean, many of your arguments for the superiority of Novell over UNIX strike ]me as more marketspeak than tech speak. We might as well claim that a UNIX ]NFS server is superior to a Novell server because it doesn't have the ]"additional baggage" of dealing with DOS and Mac files. Which might sound >good but the statement is pretty content-free. > I can appreciate your position Steve, but pure benchmarking of systems provides some pretty amazing results. We see up to 3.5 Mbytes/second come out of a Novell subsystem. (Granted the wire slows it to a crawl...) On the UNIX side, we have been able to attain 1.15 Mbytes/sec through the filesystem. The main reason is that nearly every UNIX on the market insists on building systems for the least common denominator. I.e. they are supporting the dumb ST-506 style of disk interface. Novell has seen fit to provide high-level constructs for driver writers. This allows us to build requests to the disk as large as 3-4 Megabytes. Meanwhile UNIX is stuck in the 1-8k request range. One only needs to look at the performance curves of drives to see that highest throughputs are attained at requests of greater than 64K. I don't particularly like the way things are. I much prefer UNIX to Novell. However, If you are going to pick on Novell, you should attack the namespace problem and other serious drawbacks. The performance issue is fairly black and white. :-( Bill Brothers Storage Dimensions, Inc. billbr@xstor.COM
brian@cimage.com (Brian Kelley) (03/01/91)
In article <1991Mar01.050450.17708@xstor.com> billbr@xstor.com (Bill Brothers) writes: >I can appreciate your position Steve, but pure benchmarking of systems >provides some pretty amazing results. We see up to 3.5 Mbytes/second >come out of a Novell subsystem. (Granted the wire slows it to a >crawl...) On the UNIX side, we have been able to attain 1.15 Mbytes/sec >through the filesystem. The main reason is that nearly every UNIX >on the market insists on building systems for the least common >denominator. I.e. they are supporting the dumb ST-506 style of >disk interface. Novell has seen fit to provide high-level constructs >for driver writers. This allows us to build requests to the disk >as large as 3-4 Megabytes. Meanwhile UNIX is stuck in the 1-8k >request range. And what happens to your hard mounted NFS clients when your server goes down, losing 3-4 megabytes of cached data? >Bill Brothers >Storage Dimensions, Inc. >billbr@xstor.COM --- brian@cimage.com
dyer@spdcc.COM (Steve Dyer) (03/03/91)
In article <6638@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: >It's not only not the cheapest, it's also quite deficient. How many >Unix people are going to like the filenaming limitations imposed by >the DOS filesystem? (eight characters, then a dot, then three more; >characters like comma and plus are restricted; etc.) Rich, are you pulling my leg, or does a Novell NFS file server impose DOS filename restrictions on the NFS client?? Could someone at Novell comment on this? In the same vein, is this also true for Macintosh naming conventions when using a Netware server with Appletalk support as an Apple AFP fileserver? -- Steve Dyer dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer dyer@arktouros.mit.edu, dyer@hstbme.mit.edu
wittmann@erb1.engr.wisc.edu (art wittmann) (03/04/91)
In article <6698@spdcc.SPDCC.COM> dyer@spdcc.COM (Steve Dyer) writes: >In article <6638@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: >>It's not only not the cheapest, it's also quite deficient. How many >>Unix people are going to like the filenaming limitations imposed by >>the DOS filesystem? (eight characters, then a dot, then three more; >>characters like comma and plus are restricted; etc.) > >Rich, are you pulling my leg, or does a Novell NFS file server >impose DOS filename restrictions on the NFS client?? > >Could someone at Novell comment on this? > >In the same vein, is this also true for Macintosh naming conventions >when using a Netware server with Appletalk support as an Apple AFP >fileserver? > Netware 3.x supports the idea of multiple name spaces, so, macs create files with that adhere to the mac rules, Unix machines create files that follow the Unix conventions. I just created a file called: arts_really_long_file_name, the file created without a problem. On a DOS system the file appears to be called ARTS_REA, on a mac the file is: arts_really_long_file_name. For macs, if the file name exceeds 32 characters, it's just truncated. The only real problem that I've noticed is translating mac names into NFS names. spaces and slashes aren't translated into other characters, so you may have problems referencing mac files from Unix systems. Art =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Art Wittmann Phone: (608) 263-1748 Network Manager Email: wittmann@engr.wisc.edu Computer Aided Engineering Center or: wittmann@cae.wisc.edu University of Wisconsin, Madison
karinc@isc.intel.com (Karin Coffee) (03/05/91)
In article <6648@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: >I'm curious: for a customer who is getting 3.11 Netware from Novell, when >it comes out, what is the additional cost increment to get the NFS NLM? > >-rich I, too, am getting an automatic update to 3.11 with the Mac.NLM. According to the February 18, 1991, issue of _LAN Times_, Netware NFS 1.0 retails for $4995. My vendor quoted to me $4,000. The article about Netware 3.11 and the NLMs finally answered many of the questions that we have had. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Karin Coffee Intel Supercomputer Systems Division Network/System Administration 15201 NW Greenbrier Parkway The LAN Lords Beaverton, OR 97201 karinc@isc.intel.com (503) 629-7693 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
keith@ca.excelan.com (Keith Brown) (03/06/91)
The News Manager) Nntp-Posting-Host: ca Reply-To: keith@ca.excelan.com (Keith Brown) Organization: Novell, Inc. San Jose, California References: <1991Feb21.234900.11916@novell.com> <6614@spdcc.SPDCC.COM> Date: Wed, 27 Feb 1991 21:09:37 GMT In article <6614@spdcc.SPDCC.COM> dyer@spdcc.COM (Steve Dyer) writes: > >While I am willing to suspend my disbelief (until I try it) that a >Netware NFS server might be superior to a UNIX NFS server, a lot of what >you say is a red herring. Did I say a NetWare NFS server was *superior* to a UNIX NFS server? I think not, but obviously if thats the impression I gave you then my words were at fault. We are considerably different than a UNIX based NFS server (hows that? :-), and the fact is that our differences from UNIX based NFS servers, both in the design of NetWare NFS and the design and operation of the underlying operating system on which we rely, gives us considerable performance advantages over UNIX based NFS server software running on a comparable hardware platform. If "superior"=faster then I'm sure you will be able to go and find yourself a UNIX based NFS server that is "superior" to NetWare NFS. How? Well, go to your bank manager and ask him to lend you at least a hundred thousand dollars, then, install a false floor in your office, a three phase power supply and a large air conditioning unit. Go to one of the vendors of dirty great UNIX based NFS serving throbulators and give them all your remaining money (you may have to hold some back in order to pay the crane operator to lower the machine into your office through the window). Then, light the blue touch paper and stand well back....... OK, so I may be exagerating a little but, to put my original posting back into context, I was merely having a crack at providing a justification of our $4995 price tag to someone who'd asked for it. Moving on to your comments on my market speak..... > >Now, attempting to compare oranges to tangelos, if you've got a UNIX machine >dedicated as NFS server (the analog of a Novell file server--remember, one >of these is not going to run 123 at the same time), mostly running nfsd >processes, there's no swapping or paging involved, except to handle whatever >extraneous non-NFS activity there might be (and this presumably would be >controlled by the sysmgr.) Yes, I know, but still: Probability of a UNIX based NFS server having to go to the disk sometime to retrieve swapped or paged data = SOME. Probability of NetWare NFS having to go to the disk to retrieve swapped or paged data = NILL. > Nfsd processes have their own context but run >in the kernel's address space. In other words, "everything is in kernel >space" on a UNIX NFS server, too. That is, one which is based on the Sun >reference kernel implementation (read: almost every single one.) Yes, I know that too, but being a general purpose OS, UNIX has a great deal more to worry about when it switches contexts than we do. Simply put, no provisions were made in NetWare v3.11's scheduling algorithm to attempt to provide prompt service to a frustrated spreadsheet user sitting on the end of a tty whos just punched the recalc key after sitting idle for 30 minutes. All we really care about is network and disk. Actually, printers are a minor annoyance :-) I purposely didn't mention some of the other advantages we have in the area of disk throughput. We could spend a great deal of time debating the advantages/disadvantages of our Cached FAT/Turbo FAT disk access methods over the UNIX inode/indirect block access method, but lets do it privately as I wouldn't want to be the cause of a flurry of "Please unsubscribe me" messages on this group :-) > >I mean, many of your arguments for the superiority of Novell over UNIX strike >me as more marketspeak than tech speak. Please, please don't put words like that into my mouth. You make it sound like a spend all day sitting at a NetWare v3.11 console because I'm convinced it will run yacc, awk and lex faster than if I were sat at a UNIX terminal! > We might as well claim that a UNIX >NFS server is superior to a Novell server because it doesn't have the >"additional baggage" of dealing with DOS and Mac files. And I could counter this with a "NetWare is a superior NFS server to UNIX simply because it *CAN* provide fast native file service to MS-DOS and Macintosh machines concurrently", but this groups in luck. It's lunchtime......... 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
donp@na.excelan.com (don provan) (03/06/91)
The News Manager) Nntp-Posting-Host: na Reply-To: donp@novell.com (don provan) Organization: Novell, Inc., San Jose, California References: <6638@spdcc.SPDCC.COM> Date: Thu, 28 Feb 1991 17:50:58 GMT In article <6638@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: >It's not only not the cheapest, it's also quite deficient. How many >Unix people are going to like the filenaming limitations imposed by >the DOS filesystem? (eight characters, then a dot, then three more; >characters like comma and plus are restricted; etc.) Your information is incorrect. Any legal UNIX file name is legal in Novell's NFS; it does *not* limit itself to legal DOS names. >I forgot to mention in my earlier article that SCO, Sun, et al sell an >NFS _client_ along with their _server_. Is the Novell solution also >going to offer a DOS _client_ NFS package? I doubt that Novell is in >that business. Novell provides a DOS *NetWare* client with their server. What would be the point of also offering a DOS NFS client in the same package? I dare say the NetWare client provides much better connectivity with the NetWare server than an NFS client could. don provan donp@novell.com
keith@ca.excelan.com (Keith Brown) (03/06/91)
The News Manager) Nntp-Posting-Host: ca Reply-To: keith@ca.excelan.com (Keith Brown) Organization: Novell, Inc. San Jose, California References: <1991Feb21.234900.11916@novell.com> <6614@spdcc.SPDCC.COM> <6638@spdcc.SPDCC.COM> Date: Thu, 28 Feb 1991 21:15:56 GMT In article <6638@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: > >It's not only not the cheapest, it's also quite deficient. How many >Unix people are going to like the filenaming limitations imposed by >the DOS filesystem? (eight characters, then a dot, then three more; >characters like comma and plus are restricted; etc.) My, my. You are well informed! Tell me who your informant is so I can go hit him with something. Here's an "ls -la" listing of a directory I mounted in from a NetWare NFS server. The second file on the list I put there exclusively for your benefit! total 13444 drwxrwxrwx 2 nobody 512 Feb 28 04:40 . drwxr-xr-x 15 root 1024 Feb 27 15:39 .. -rw-r--r-- 1 keith 11281200 Jan 30 13:58 10Meg -rwxr-xr-x 1 keith 1401323 Feb 28 04:37 A very large file with an extremely long name containing spaces and wierd characters just to prove it can be done $%@^*()[] -rw-rw-rw- 1 keith 2374 Jan 22 11:34 alberty.wkz -rwxrwxrwx 1 keith 1131 Oct 1 10:19 finance.wkz -rw-r--r-- 1 keith 61 Feb 27 08:05 junk -rw-r--r-- 1 keith 0 Feb 28 04:40 lsoutput -rwxrwxrwx 1 keith 1218 Jan 15 17:19 plotit -rwxr-xr-x 1 keith 1076048 Feb 27 08:29 vmunix > >My challenge was answered privately by e-mail from a Novell person who >said, in effect, laugh at us later if we don't manage to rake in the >bucks on this one. And also suggesting they're justified in setting the >price high because Unix users have come to expect NFS server capability >as standard issue, but Novell has to charge the money for NFS users because >they don't think standard Netware users should have to subsidize NFS users. Care to copy me on this alleged E-Mail? If this is in fact what a Novell employee told you, I shall make a point of straightening their view of the world personally! > >I forgot to mention in my earlier article that SCO, Sun, et al sell an >NFS _client_ along with their _server_. Is the Novell solution also >going to offer a DOS _client_ NFS package? I doubt that Novell is in >that business. Wrong again! We already offer a DOS client TCP/IP package. Although we haven't developed a client NFS piece for it ourselves, we actively refer customers who need this capability to Beame and Whiteside who have been kind enough to fill this "hole" for us with a special port of their NFS client software for DOS (using our underlying transport). > >I'd suspect a company like Atlantix should be well-positioned to mount a >serious challenge in this area. And in the finest traditions of the net, I wish them well..... I am reasonably familiar with the Atlantix offering. I'm having a little trouble with your reasoning though? > >By way of disclaimer, I'd like to point out that my company is not in the >business of providing DOS or Unix network solutions to its customers; Hmmm. This is probably just as well :-) 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
keith@ka.excelan.com (Keith Brown) (03/06/91)
The News Manager) Nntp-Posting-Host: ka Reply-To: keith@ka.excelan.com (Keith Brown) Organization: Novell, Inc. San Jose, California References: <1991Feb21.234900.11916@novell.com> <6614@spdcc.SPDCC.COM> <1991Mar01.050450.17708@xstor.com> <1991Mar1.145839.13285@cimage.com> Date: Sat, 2 Mar 1991 01:33:01 GMT In article <1991Mar1.145839.13285@cimage.com> brian@dgsi.UUCP (Brian Kelley) writes: > >And what happens to your hard mounted NFS clients when your server goes down, >losing 3-4 megabytes of cached data? > This needn't be an issue if you don't want it to be. One of the configuration parameters of NetWare NFS is "CACHE_WRITE_THROUGH". Setting this parameter to "on" puts us into "UNIX mode" and we dutifully make sure write operations to the server hit the magnetic dots before we respond to the request. As you would expect, this will cost you some performance but we still find that we're head and shoulders above UNICES on a comparable hardware platform. However, you will note that it is possible to make the NetWare v3.11 underlying file system rather robust, rather cheaply. Buy yourself a second hard disk, plug it into your controller and fire up our disk mirroring capabilities and you just guarded your 3-4 megabytes of cached data against a disk failure. Splash out on an additional HD controller, fire up our disk duplexing features and you just protected your 3-4 megabytes of cached data against a disk or controller failure. Buy yourself an uninterruptible power supply and load up UPS.NLM and you just guarded your 3-4 megabytes of cached data against your local klutz kicking the plug out of the wall. Etc..... NetWare v3.11 does try to flush it's caches within 3 seconds if it can anyway, so thats still a little better than your average UNIX system. I'm uncertain as to which UNICES actually have the ability to disable cache write through at all? Perhaps it can be done on some by adb(1)ing the kernel. Anyone care to enlighten me? It still wouldn't buy UNIX based NFS servers very much though. Why? Well, someone once told me that UNIX systems have these things called user processes to be concerned about. If this is indeed the case, that must mean they are unable to blow open every last byte of their remaining memory to an enormous disk cache. Hmm... I imagine that this must severely impact their ability as NFS servers? Could this be true?? I wonder! 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
tb@Materna.DE (Torsten Beyer) (03/06/91)
keith@ca.excelan.com (Keith Brown) writes: >> Nfsd processes have their own context but run >>in the kernel's address space. In other words, "everything is in kernel >>space" on a UNIX NFS server, too. That is, one which is based on the Sun >>reference kernel implementation (read: almost every single one.) >Yes, I know that too, but being a general purpose OS, UNIX has a great >deal more to worry about when it switches contexts than we do. Simply >put, no provisions were made in NetWare v3.11's scheduling algorithm to >attempt to provide prompt service to a frustrated spreadsheet user >sitting on the end of a tty whos just punched the recalc key after sitting Maybe you are right, BUT in a networked environment usually NFS-Server ONLY do NFS. That is these NFS-Server do not have to care about any frustrated whatsoever users. They just answer NFS-calls. And even if they had to. I have done quiete some NFS testing and benchmarking and usually the bottleneck in NFS performance was disk throughput. Nothing but that. 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. 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. >I purposely didn't mention some of the other advantages we have in the area >of disk throughput. We could spend a great deal of time debating the >advantages/disadvantages of our Cached FAT/Turbo FAT disk access methods >over the UNIX inode/indirect block access method, but lets do it privately 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)?. I'm not convinced that this is so important. The amount of blocks you can read in a given time to me seems to the most important factor. Don't stop this discussion here as it starts to interest me..... ciao -Torsten -- 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
alan@curly.Viewlogic.COM (Alan Medsker) (03/07/91)
Re: NFS performance on NetWare 3.x I've heard that Novell has seen a NetWare 3.x NFS server handle twice the NFS IOPS as a dedicated SPARCstation (2, I think) can. I don't know if they did this for the test, but you can turn off the write-through-to-novoltile-storage requirement for NetWare/NFS if you like, which significantly speeds things up. Alan -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alan Medsker Viewlogic Systems, Inc. Voice: (508) 480-0881 293 Boston Post Road West Fax: (508) 480-0882 Marlboro, MA 01752 Internet: amedsker@Viewlogic.COM cc:Mail: Alan Medsker at Viewlogic CI$: 76376,662 BIX: amedsker 2 Meters: WB0SQR =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= My opinions, of course. And don't hold me to them. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
tb@Materna.DE (Torsten Beyer) (03/07/91)
This starts to get really funny.... keith@ka.excelan.com (Keith Brown) writes: >I'm uncertain as to which UNICES actually have the ability to disable >cache write through at all? Perhaps it can be done on some by adb(1)ing >the kernel. Anyone care to enlighten me? It still wouldn't buy UNIX based >NFS servers very much though. Well, to my opinion switching this write-through off means to violate the protocol. I mean NFS is stateless and when the server says "Allright pal, your data's here in my hands" tha client has to bs SURE that this is really the case. Ok, now you come with your mirror disks and all this stuff.. but I think it's the wrong way to REEINSTALL NFS semantics. Bovell NFS should behave like ordinary NFS righ away not only after installing lots of junk in the server... >Why? Well, someone once told me that UNIX systems have these things >called user processes to be concerned about. If this is indeed the >case, that must mean they are unable to blow open every last byte of >their remaining memory to an enormous disk cache. Hmm... I imagine that >this must severely impact their ability as NFS servers? Could this be >true?? I wonder! Depends. Suns (since SunOS 4.0) for example use all their free memory as buffer cache. As I pointed out in an earlier message, my experience is that servers are servers and just do that job. NO spreadsheet users and stuff. This means that you can get a really large buffer cache (~5 Mb I'd guess on an 8 Mb Sun server). ciao -Torsten -- 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
keith@ca.excelan.com (Keith Brown) (03/07/91)
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> <tb.668271346@elwood> Date: Thu, 7 Mar 1991 07:43:17 GMT In article <tb.668271346@elwood> 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
alan@curly.Viewlogic.COM (Alan Medsker) (03/08/91)
In article <6638@spdcc.SPDCC.COM>, rbraun@spdcc.COM (Rich Braun) writes: |> |> It's not only not the cheapest, it's also quite deficient. How many |> Unix people are going to like the filenaming limitations imposed by |> the DOS filesystem? (eight characters, then a dot, then three more; |> characters like comma and plus are restricted; etc.) |> Have you actually seen the NetWare/NFS product, or any of its documentation? I think you'll probably find that the file naming limitations are not there if you don't want them to be (although you may want to stick with them for interoperability purposes). After all, NetWare allows wierdo Mac file names... Remember, you are *NOT* dealing with DOS here. It's NetWare, which has all sorts of things in its file system that DOS doesn't have (last access date, long file names, file ownership and protection). In fact, it's probably better thought of as a superset of Unix or DOS file systems. C'mon, let's not trash them (Novell) before we see how it all works. From what I've seen, this product will be well worth it in my environment (125 PCs, four NetWare servers, 100 Unix workstations, a few Macs) to greatly enhance interoperability, if nothing else. Alan -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alan Medsker Viewlogic Systems, Inc. Voice: (508) 480-0881 293 Boston Post Road West Fax: (508) 480-0882 Marlboro, MA 01752 Internet: amedsker@Viewlogic.COM cc:Mail: Alan Medsker at Viewlogic CI$: 76376,662 BIX: amedsker 2 Meters: WB0SQR =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= My opinions, of course. And don't hold me to them. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
tb@Materna.DE (Torsten Beyer) (03/08/91)
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
saddison@ca.excelan.com (Skip Addison) (03/09/91)
The News Manager) Nntp-Posting-Host: ca Reply-To: saddison@Novell.com (Skip Addison) Organization: Novell, Sunnyvale, CA References: <1991Mar7.074317.26918@novell.com> <tb.668418489@elwood> Date: Fri, 8 Mar 1991 14:54:30 GMT In article <tb.668418489@elwood> tb@Materna.DE (Torsten Beyer) writes: > ... >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 >... As Unix machines increasingly move into the business world, they're increasingly running database applications. Random I/O with seeks all over the place is the norm for these applications. -- Skip
rbraun@spdcc.COM (Rich Braun) (03/10/91)
I wrote: >>Is the Novell solution also going to offer a DOS _client_ NFS package? From Novell, donp@na.excelan.com (don provan) writes: >Novell provides a DOS *NetWare* client with their server. What would >be the point of also offering a DOS NFS client in the same package? I >dare say the NetWare client provides much better connectivity with the >NetWare server than an NFS client could. You seem to be in your own little DOS world. What would be the point? My friend, interoperability's the point. If you add an NFS server to your Netware servers, Unix users can then get access to files stored on them. But DOS users are still stuck with accessing only files on the Novell servers, unless Portable Netware is installed on the Unix systems. It's basically half-a-loaf. On the one hand, you're encouraging companies to add TCP/IP Unix systems to their Novell networks, and on the other you're not providing comparable access for DOS users. But my argument was basically to dramatize the difference in the functionality/price ratio between the Novell NFS NLM and NFS products from Unix vendors, which always include an NFS client with the NFS server. Novell need not get into this business because NFS client packages for DOS are available from other vendors. All of this actually surprises me, because I'm used to running into high prices in the Unix marketplace. For the DOS marketplace to offer higher prices than corresponding Unix products, this is new to me. I stand corrected on the filenaming argument I posed earlier, and will have to withhold any technical criticism of the product until I've seen it, which probably won't be for another 6 months due to the fact that my company is unlikely to shell out the $4-5 grand until then. -rich
kusumoto@chsun1.uchicago.edu (Bob Kusumoto) (03/10/91)
I think there is a good arguement for having an NFS client for DOS machines
(well at least for the NW server).
Example:
we're going to be picking up a nice little machine known as an Epoch (basically
an NFS server with anywhere between 1 and 1000GB of storage, divided between
hard drives and optical devices). Since this little baby handles file
archiving to it's optical devices for long term storage for files that are
rarely accessed, it would be really nice to use from our Novell network,
either having a PC do an NFS drive mapping to some directory on it, or
have the server mount a directory from it.
The point I'm making here is that the NFS option needs to be able to mount
a remote NFS drive as a volume on the server or at least having DOS clients
to map an NFS drive to the NFS server.
It sounds like the current NFS NLM sounds good, given enough space for your
NFS clients, but there really needs to be two-way NFS support.
Bob
--
Bob Kusumoto | I just come from the land of
Internet: kusumoto@chsun1.uchicago.edu | the sun/ from a war that must
Bitnet: kusumoto%chsun1@uchicago[.bitnet] | be won in the name of truth.
UUCP: ...!{oddjob,gargoyle}!chsun1!kusumoto | - New Order, "Love Vigilantes"donp@na.excelan.com (don provan) (03/11/91)
The News Manager) Nntp-Posting-Host: na Reply-To: donp@novell.com (don provan) Organization: Novell, Inc., San Jose, California References: <6807@spdcc.SPDCC.COM> Date: Sat, 9 Mar 1991 23:00:16 GMT In article <6807@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: >I wrote: >>>Is the Novell solution also going to offer a DOS _client_ NFS package? > >From Novell, donp@na.excelan.com (don provan) writes: >>Novell provides a DOS *NetWare* client with their server. What would >>be the point of also offering a DOS NFS client in the same package? I >>dare say the NetWare client provides much better connectivity with the >>NetWare server than an NFS client could. > >What would be the point? My friend, interoperability's the point. Providing interoperability would be a justification for providing a DOS NFS client as a separate product, but it provides very little value as a piece of an NFS product built on top of NetWare. >But DOS users are still stuck with accessing only files on the Novell >servers, unless Portable Netware is installed on the Unix systems. But you just told us that all those other NFS systems come with a DOS NFS, so they're already set. They *have* to provide DOS NFS to provide themselves DOS connectivity. My point was that NetWare already has better DOS connectivity, so an NFS DOS client would be redundant for NetWare's NFS product. don provan donp@novell.com
keith@ca.excelan.com (Keith Brown) (03/11/91)
The News Manager) Nntp-Posting-Host: ca Reply-To: keith@ca.excelan.com (Keith Brown) Organization: Novell, Inc. San Jose, California References: <6807@spdcc.SPDCC.COM> Date: Sun, 10 Mar 1991 04:32:16 GMT In article <6807@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: >But my argument was basically to dramatize the difference in the >functionality/price ratio between the Novell NFS NLM and NFS products >from Unix vendors, which always include an NFS client with the NFS >server. Novell need not get into this business because NFS client >packages for DOS are available from other vendors. Look, if you want to talk about the networking capabilities that come "free" with operating systems then *YES* UNIX<->UNIX TCP/IP networking comes free with many of the better version of UNIX, including NFS client and server. I know of no version of UNIX that bundles DOS internetworking capabilities. Sun could throw the PC-NFS executables into SunOS, but they haven't. On the other hand, multitudenous DOS/PC networking capabilities are what come "free" with our operating system. Just as UNIXs typically don't bundle their DOS interoperability options, we haven't bundled our UNIX interoperability options. Both Sun and Novell employ people who need money to pay mortgages. This, I believe, is why the world looks the way it does. Sorry..... 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
keith@ca.excelan.com (Keith Brown) (03/11/91)
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> <tb.668418489@elwood> Date: Sun, 10 Mar 1991 04:18:35 GMT In article <tb.668418489@elwood> 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
wittmann@erb1.engr.wisc.edu (art wittmann) (03/12/91)
In article <1991Mar6.171901@curly.Viewlogic.COM> alan@curly.Viewlogic.COM (Alan Medsker) writes: >Re: NFS performance on NetWare 3.x > >I've heard that Novell has seen a NetWare 3.x NFS server handle twice the NFS IOPS as a >dedicated SPARCstation (2, I think) can. I don't know if they did this for the test, but >you can turn off the write-through-to-novoltile-storage requirement for NetWare/NFS if you >like, which significantly speeds things up. > >Alan >-- I've been doing some _Purely Unscientific_ benchmarks that I thought I would share with you. My tests involve three servers a one client architecture. Since there have been so many comments on the relative performance expectations, I wanted to post my current stats. I should mention that these tests involve beta software from Novell, so the end version may perform better. Novell Knows about my tests, but has not helped in performing them. These results are from a single station test, I will try to publish multiple station tests in a week or so. The servers are: Netware 386 on a 25 Mhz 486 HP EISA machine (14 Mbytes memory, ESDI DISK ) SUN OS 4.11 on a Sparcstation 1+ (16 Mbytes memory, SCSI DISK) HP-UX 7.0 on an HP 9000/345 (25 Mhz 68030, 16 Mbyte memory, SCSI DISK) The client in all tests is a sparcstation IPC. The test involves the reading and writing of a one megabyte file (a copy of the sun os kernel on my IPC). All times are in seconds, in the form best time / worst time / average time for five iterations of my test. Novell Server Sparc 1+ HP 9000/345 NFS to local 1.6 /3.5 /2.0 1.6 /2.4 /1.78 1.6 /2.5 /1.78 NFS to wc 3.1 /3.9 /3.32 2.7 /3.6 /2.96 2.6 /2.7 /2.66 local to NFS 9.4 /19.8/13.3 12.3/13.4/12.84 12.2/12.8/12.5 NFS to NFS 7.2 /22.0/14.84 12.7/14.1/13.24 11.5/13.3/12.06 Total 29.0/45.1/36.7 31.4/34.5/32.44 30.1/33.2/30.96 In the second line, wc is the word count program. Note that all machines are real world servers. No 'tuning' has been done for NFS on any of them. The novell server has both netware NFS and Netware for Mac loaded. In some previous tests, the Novell server actually outperformed the other architectures. This was under very light network load. In that case, Netware was about 1.5 seconds better than HP and 2 seconds better than the sparcstation 1+. These tests were done on an ethernet network with about 8 - 12% standing bandwidth usage (as measured with a sniffer). I hope to publish a 3 station and five station test soon. My feeling is that multiple station tests will show more variation, and be more indicative of true performance. In any event I feel my tests seem to show that these stations are all in the same ballpark. Art =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Art Wittmann Phone: (608) 263-1748 Network Manager Email: wittmann@engr.wisc.edu Computer Aided Engineering Center or: wittmann@cae.wisc.edu University of Wisconsin, Madison
dyer@spdcc.COM (Steve Dyer) (03/12/91)
In article <1991Mar10.041835.6883@novell.com> keith@ca.excelan.com (Keith Brown) writes: >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 No, it doesn't work that way. Files are paged in from disk. The paging subsystem's lists of pages (which ultimately describe all of non-kernel memory) replace the traditional UNIX disk buffer cache for file data. The only objects which use the buffer cache are file system "meta" operations like reads of on-disk inodes and indirect blocks. Now, this is (I believe) Sun OS 4.1 and (fer sure) Sys Vr4. Earlier versions of Sun OS and other vendor's UNIX systems may use a traditional disk buffer cache. The rest of this discussion is really rather moronic. I can't believe I'm reading someone describe a Netware server as "better" because it doesn't have a compiler and thus can't have its cycles and disk arms used for some other purpose. I suggest that the merits of the Novell NFS server be based on its empirically observed performance, and not on marketspeak and dubious distinctions which are irrelevant. -- Steve Dyer dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer dyer@arktouros.mit.edu, dyer@hstbme.mit.edu
saddison@ca.excelan.com (Skip Addison) (03/12/91)
The News Manager) Nntp-Posting-Host: ca Reply-To: saddison@ca.excelan.com (Skip Addison) Organization: Novell, Sunnyvale, CA References: <6807@spdcc.SPDCC.COM> Date: Mon, 11 Mar 1991 21:36:58 GMT In article <6807@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: > ... >From Novell, donp@na.excelan.com (don provan) writes: >> ... > >You seem to be in your own little DOS world. >... Don has his good and bad points just like the rest of us; however, there's one thing he's NOT, and that's "in his own little DOS world". You've unfairly stereotyped Novell employees as badly as you've stereotyped our products. -- Skip
tb@Materna.DE (Torsten Beyer) (03/12/91)
saddison@ca.excelan.com (Skip Addison) writes: Skip, >As Unix machines increasingly move into the business world, they're >increasingly running database applications. Random I/O with seeks all >over the place is the norm for these applications. Granted, BUT these don't have to be NFS-Servers ? Usually Databases build up their own filesystems anyway so you can't even use NFS. I think DB is a different story.... ciao -Torsten -- 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
backman@vaxeline.ftp.com (Larry Backman) (03/13/91)
In article <6807@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: >I wrote: >>>Is the Novell solution also going to offer a DOS _client_ NFS package? > >From Novell, donp@na.excelan.com (don provan) writes: >>Novell provides a DOS *NetWare* client with their server. What would >>be the point of also offering a DOS NFS client in the same package? I > >You seem to be in your own little DOS world. What would be the point? I think before you castigate Don so publically that you should remember that he has been one of the voices of interoperability & connectivity from Novell over the past 2 years. >My friend, interoperability's the point. If you add an NFS server to >your Netware servers, Unix users can then get access to files stored >on them. But DOS users are still stuck with accessing only files on >the Novell servers, unless Portable Netware is installed on the Unix >systems. That sure sounds like a stretegic decision made at levels in Novell far, far above those writing on the Internet... It's basically half-a-loaf. On the one hand, you're encouraging >companies to add TCP/IP Unix systems to their Novell networks, and on the >other you're not providing comparable access for DOS users. > Again; a strategic decision, if you control the servers; you control the network; or something like that.... >All of this actually surprises me, because I'm used to running into >high prices in the Unix marketplace. For the DOS marketplace to offer >higher prices than corresponding Unix products, this is new to me. > yes the prices are high; so is a Sparc-II by the time you add all the bells & whistles to it. Yes also, Sun's NFSD is free but bundled software isn't always given the loving care that a software only product is. I personally would love to spend 4-5K for a server that is reliable (Checksums Don?) does intelligent datagram adapation based on MTU size as well as whetehr or not a router is involved. In addition I'd love to see an NFS Server that screams, as opposed to clunks as many of the other < $50,000 NFS Servers seem to do. a Larry Backman backman@ftp.com
tb@Materna.DE (Torsten Beyer) (03/15/91)
Keith, keith@ca.excelan.com (Keith Brown) writes: >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 I'm not sure, but I believe you won't find anything about that in the docs. Sun changed their memory management dramatically when they went to 4.x. The new design basically maps every fileacces to paging. So files don't get read in the way they used to in the old days (via the buffer cache) instead they get PAGED in. The trick now is that all pages reside on a page list which more or less works like an LRU list. So once a file get's paged in, it'll stay in it's pages until the kernel decides somebody else could use these pages in a better way. As all memory (except for kernel memory and static kernel structures) is in the page pool, this memory CAN act as a buffer cache. Considering a configuration where a system only acts as an NFS server, it's very likely that most unused processes will be swapped to disk, thus freeing up real memory as buffer pages. This is basicaly the way it works (if I remember correctly). I used to know all this a lot better, when I had access to the SunOS 4.0 source, which is about a year ago. Sun presented some papers about their memory management strategies at USENIX conferences (i think in 88 and 89). Offhand I don't know the exacy conferences and names of the authors. If you are interested I'll scan my desk and homedirectory to find more precise information. >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 Like I said, there is no explicit point at which a server says that. The "decision" depends on what the system does. Acting only as an NFS server will put the system in the described state within a minute or so. It's just that more and more pages are used by files. >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? This is where your anti-UNIX argument is right. At this point the kernel will, according to it's paging strategy, throw out (file)pages in order to get memory for the make and it's children. This will certainly degrade the fileserving performance >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 Unfortunately this articel arrived here one day too late. I visited CeBIT yesterday and tried to find somebody at the Novell booth to show me your NFS stuff. They were however extremely unfriendly and told me it was not possible and nobody was demonstrating it... :-(. I'm certain somebody did, but I couldn't manage to find the right person (the boot was extremely packed). >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? Hmm, we have a Novell-Net here and it basically works ok. Recently however we had problems with our power supply and the server would crash regularly (of course not it's fault). This led to me loosing one hours work of typing... This wouldn't have happened if I were using NFS. ciao -Torsten -- 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
tfb@unf7.UUCP (t blakely) (03/16/91)
In article <1991Mar9.230016.3431@novell.com> donp@na.excelan.com (don provan) writes: >Providing interoperability would be a justification for providing a >DOS NFS client as a separate product, but it provides very little >value as a piece of an NFS product built on top of NetWare. So you don't think my PC users should be able to access files on the Novell server and files on my unix box via NFS at the same time? Or should I have to buy Novell's NFS server software to do this? Why not just the NFS client support? Tom Blakely tfb@sinkhole.unf.edu
cudcv@warwick.ac.uk (Rob McMahon) (03/18/91)
In article <1991Feb28.175058.16007@novell.com> donp@na.excelan.com (don provan) writes: >In article <6638@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: >>It's not only not the cheapest, it's also quite deficient. How many Unix >>people are going to like the filenaming limitations imposed by the DOS >>filesystem? > >Your information is incorrect. Any legal UNIX file name is legal in >Novell's NFS; it does *not* limit itself to legal DOS names. I've only just been pointed at this discussion, this is not a group I normally read. I also don't want to fan the flame war, tb@Materna.DE (Torsten Beyer) has already rebuked most of the more misinformed anti-Unix comments like not being able to use such a big disk cache, having to keep switching context to user mode processes etc. But I do have one serious question. We've seen the Novell NFS server supports long filenames (256 characters / component ?) with unlimited character sets (all 8 bits ?), but does it also support hard and soft links, character and block devices, named pipes, Unix domain sockets, and such ? Cheers, Rob -- UUCP: ...!mcsun!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick INET: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England
tb@Materna.DE (Torsten Beyer) (03/20/91)
cudcv@warwick.ac.uk (Rob McMahon) writes: >In article <1991Feb28.175058.16007@novell.com> donp@na.excelan.com (don >We've seen the Novell NFS server supports long filenames (256 characters / >component ?) with unlimited character sets (all 8 bits ?), but does it also >support hard and soft links, character and block devices, named pipes, Unix >domain sockets, and such ? C'mon Rob, let's be fair. Skip pipes and devices. These won't work with NFS either (although they do with RFS (to my knowledge at least, any RFS gurus outthere ?)). Links are mandatory though. ciao -Torsten -- 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
donp@na.excelan.com (don provan) (03/20/91)
The News Manager) Nntp-Posting-Host: na Reply-To: donp@novell.com (don provan) Organization: Novell, Inc., San Jose, California References: <1991Mar9.230016.3431@novell.com> <354@unf7.UUCP> Date: Tue, 19 Mar 1991 20:22:52 GMT In article <354@unf7.UUCP> tfb@unf7.UUCP (t blakely) writes: >In article <1991Mar9.230016.3431@novell.com> donp@na.excelan.com (don provan) writes: >>Providing interoperability would be a justification for providing a >>DOS NFS client as a separate product, but it provides very little >>value as a piece of an NFS product built on top of NetWare. > >So you don't think my PC users should be able to access files on the >Novell server and files on my unix box via NFS at the same time? I think your PC users should be able to do whatever they want. I'm just pointing out that there's no particular reason for you to assume that NetWare NFS should solve this problem. NetWare NFS allows NFS clients to access files on NetWare servers. I don't speak for Novell NFS development, but it strikes me that you are discussing the opposite problem: allowing PCs to access files on NFS servers. The nothing wrong with wanting to access NFS from a PC, i just don't consider the lack of a solution in NetWare NFS to be a deficiency. don provan donp@novell.com
bryan@npd.Novell.COM (Bryan Cardoza) (03/20/91)
In article <tb.669407545@elwood> tb@Materna.DE (Torsten Beyer) writes: |cudcv@warwick.ac.uk (Rob McMahon) writes: |>We've seen the Novell NFS server supports long filenames (256 characters / |>component ?) with unlimited character sets (all 8 bits ?), but does it also |>support hard and soft links, character and block devices, named pipes, Unix |>domain sockets, and such ? | |C'mon Rob, let's be fair. Skip pipes and devices. These won't work with NFS |either (although they do with RFS (to my knowledge at least, any RFS gurus |outthere ?)). Links are mandatory though. And symbolic and hard links do indeed work. -- Bryan Cardoza <bryan_cardoza@npd.novell.com> Software Engineer Novell, Inc. Telephone: (801) 568-8674 Sandy, UT Fax: (801) 568-8866
dyer@spdcc.COM (Steve Dyer) (03/21/91)
In article <tb.669407545@elwood> tb@Materna.DE (Torsten Beyer) writes: >C'mon Rob, let's be fair. Skip pipes and devices. These won't work with NFS >either (although they do with RFS (to my knowledge at least, any RFS gurus >outthere ?)). If this were true, then diskless workstations wouldn't work very well, would they? FIFOs and special devices work under NFS but they're interpreted locally on the client--they do not access resources on the server. -- Steve Dyer dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer dyer@arktouros.mit.edu, dyer@hstbme.mit.edu
jeremy@ka.novell.com (Jeremy Liang) (03/21/91)
The News Manager) Nntp-Posting-Host: ka Reply-To: jeremy@ka.novell.com (Jeremy Liang) Organization: Novell, Inc., San Jose, Ca Date: Wed, 20 Mar 1991 17:39:54 GMT cudcv@warwick.ac.uk (Rob McMahon) writes: |>We've seen the Novell NFS server supports long filenames (256 characters / |>component ?) with unlimited character sets (all 8 bits ?), but does it also |>support hard and soft links, character and block devices, named pipes, Unix |>domain sockets, and such ? | Let me set the record straight. Yes, NetWare NFS does support hard/symbolic links, character and block devices, name pipes, and UNIX domain sockets.
cudcv@warwick.ac.uk (Rob McMahon) (03/22/91)
In article <tb.669407545@elwood> tb@Materna.DE (Torsten Beyer) writes: >Skip pipes and devices. These won't work with NFS either (although they do >with RFS ...). Hmm, pipes seem to work fine for me: % ls -lg pipe prw-r--r-- 1 cudcv staff 0 Mar 21 14:20 pipe % df . Filesystem kbytes used avail capacity Mounted on orchid:/home/orchid 254785 227401 1905 99% /home/orchid % echo gronk > pipe & [1] 1874 % cat < pipe [1] Done echo gronk > pipe gronk % Emacsclient likes to create Unix domain sockets in your home directory, so pipes and sockets at least are a necessity if you have your home directory on such a server. Devices work fine too, although Joe Average User can't create them, so they're much less important. They just work differently to RFS, accessing local instead of remote devices. Which is the `right' way of working is not a discussion for this group. Cheers, Rob -- UUCP: ...!mcsun!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick INET: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England
tb@Materna.DE (Torsten Beyer) (03/22/91)
dyer@spdcc.COM (Steve Dyer) writes: >In article <tb.669407545@elwood> tb@Materna.DE (Torsten Beyer) writes: >>C'mon Rob, let's be fair. Skip pipes and devices. These won't work with NFS >>either (although they do with RFS (to my knowledge at least, any RFS gurus >If this were true, then diskless workstations wouldn't work very well, >would they? FIFOs and special devices work under NFS but they're >interpreted locally on the client--they do not access resources on >the server. Right. This was what I wanted to say with my previous posting. Pipes and stuff don't work NETWIDE. Of course they do locally.... This however brings up the question if a Novell-NFS-Server could be used as the server of a diskless machine. And you are right, if the Novell ppl do not support Pipes/Devices it probably won't do the job. Comments anyone ? -- 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
david@slc6.INS.CWRU.Edu (David Nerenberg) (03/25/91)
>I don't speak for Novell NFS development, but it strikes me that you are >discussing the opposite problem: allowing PCs to access files on NFS >servers. This is one of the things we would like to be able to do. We already own rather large disks for Unix/Sun/NFS systems, and would love to "link" the netware need to these disks. For me here, it would certainly beat having to buy more disks just for netware, and others just for NFS. Dave -- david@ins.cwru.edu David Nerenberg 73107,177 Compuserve Information Network Services NY: H-516-751-6344 Case Western Reserve University W-516-751-8111 W-216-368-2982 H-216-754-2063