NFS and SCO
Posted in 1994
Topics: Performance & Tuning, Networking & sqlhosts Configuration, Licensing & Editions
A couple weeks ago I made the following post to the net: My office is considering the use of NFS as a productivity enhancer. Currently we use rlogin to allow users to connect to services we have only on one machine or the other. We have three machines, all running SCO Unix. We hope to use NFS so that users can do it all from one menu on one machine. Is this possible? Below are is a list of some specific questions. 1. Can we run applications (a C program, shell scripts, perl scripts, etc) that are on the remote computer? What kind of performance can be expected? 2. What are the software requirements to get NFS to work? We have TCP/IP, but not ODT. 3. How well does Informix work with NFS? Do we need to get I-Net or some such, or can we just mount the remote file system and pretend it is local? 4. How well does WordPerfect work with NFS? 5. How difficult to administer is NFS? 5. Are there any special factors I should consider? On the whole, what is your opinion of NFS? I will be contacting SCO with similar questions, but I wanted the input of people who have actually been using NFS and who do not have an economic stake in my decision. Please respond via email and I will summarize in a week or so. To summarize the responses ran about as follows: 1) should work and look just like a local program since NFS mounts the remote filesystems on your local computer. Your local computer then tries to access the remote filesystem as if it were another hard drive. This should rarely produce any performance losses. 2) All that is needed is NFS and TCP/IP. 3) Informix SE will only work over NFS with I-Net due to locking considerations. I contacted Informix and they confirmed this, but also indicated that version 6 of SE will include the I-Net stuff required to work over NFS. 4) WordPerfect will work just like any other normal program (See question 1). 5) NFS does present a learning curve, but is not terribly difficult to work with once that curve is overcome. 6) There are varying opinions on SCO NFS. Some like it, some hate it. Read the responses to get a feel for who others view it. One guy called me to tell me how much he loves SCO NFS. Below are the responses I received to this post. Thank you to all those who took the time to respond to my post. ********** From: maklinm@cognos.COM We are a development shop and have had nothing but problems with SCO's NFS. Though we are using NFS in a very heterogenous environment. > 1. Can we run applications (a C program, shell scripts, perl scripts, etc) > that are on the remote computer? What kind of performance can be > expected? Yes. The performance will vary depending on too many factors to give a single answer. If you plan to performance tune NFS you will need to understand what nfsd, biod, buffer cache, etc. THE "bible" is from Hal Stern from Sun (they developed and license NFS) by O'Reilly Assoc., called "Managing NFS and NIS" or something like that. Great insight for current implementations of NFS. > 2. What are the software requirements to get NFS to work? We have TCP/IP, > but not ODT. NFS runs on top of TCP/IP. If I remember right NFS is shipped with TCP/IP. A man nfsd or man rpc.mountd will let you know if you have some of the pieces you will need. > 3. How well does Informix work with NFS? Do we need to get I-Net or some > such, or can we just mount the remote file system and pretend it is local? There is I believe a way to run Informix across NFS. It is documented in their FAQ. If you receive USENET check comp.databases.informix and look for it there. Or you could go to rtfm.mit.edu as the official FAQ archive site. I believe you do not need I-Net. > 4. How well does WordPerfect work with NFS? For the most part it should work. I have heard of many problems with PC-based apps on SCO due to the locking mechanisms employed by the apps. The single biggest problem with NFS is rpc.lockd, the lock manager. You will have to check with WordPerfect. They have quite a few licenses on SCO, so they should know how it works. > 5. How difficult to administer is NFS? The difficulty you will run into is maintaining UID and GID synchronization amongst your distributed files. A way to make it easier is to use NIS. But SCO's NIS implementation is quite a bit different then other vendors and we have had quite a few problems with it. Your mileage will vary. > 5. Are there any special factors I should consider? On the whole, what is > your opinion of NFS? As long as all your boxes are SCO then it should be OK. We have had nothing but problems with SCO's NFS because we use it as client to an HPUX file server. Because SCO insists on maintaining compatiability with their Xenix base, inode values are only 16-bits wide. That creates lots of problems when the NFS server file system supports and records 32-bit inodes. We have had our SCO servers just hang. The worst is that SCO support acknowledges the problem but can not do anything about it. Out of all the Unix platforms we support here SCO is the only one that we have any issues with NFS. Ahh well, rumor has it that ODT 4.0 (SCO/UX ???) will finally support 32-bit inodes, so things should get better, but we will have to wait. ************ From: jeff@medsup.com NFS from one SCO system to another can be a drag. You build interdependent relationships among the servers and when one of them has a problem it affects the entire domain. Note that I'm not stating that NFS in general is a drag -- just using a functioning SCO server to act as the NFS host is asking for trouble in a production environment. Our solution here is to use a special NFS server: FAServer from Network Appliance Corp. It offers very high throughput, incredible reliability (RAID 4) at a reasonably modest cost: $20K when configured with 64MB RAM + 4 2GB driver (hot-swappable). Ours system has been up continuously for 197 days without a single glitch. We were apparently the first company to attach one (via 10BaseT) to a set of SCO boxes. The reason that this reliability is so important for NFS isn't just because you can't access the files when a SCO server drops; when this occurs, it causes all sorts of problems throughout the network. The other thing you'll want to look into is NIS management, particularly of your user accounts. We have NIS manage all user accounts on 5 SCO servers. Their home directories all reside on the FAServer. This means that anyone can login to any server at any time. Since their terminals are routed through a terminal server (Corollary) we can move a user from one SCO box to another with a minimum of fuss. As far as most of our users are concerned, they no longer care which machine they have logged into, as long as they get decent response time. (As you can see, this makes it reasonably easy to balance the user load.) Good luck with NFS. I'll be happy to discuss the FAServer with you if you're interested in more info: (205) 926-3700 Jeff Bauer I have no connection with Network Appliance -- just a satisfied customer. jeff@medsup.com \