Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!acd4!mjb From: mjb@acd4.UUCP ( Mike Bryan ) Newsgroups: comp.protocols.nfs Subject: Re: NFS client has out-of-date files Message-ID: <1989Oct9.191726.23428@acd4.UUCP> Date: 9 Oct 89 19:17:26 GMT References: <17787@bellcore.bellcore.com> <1967@convex.UUCP> <1989Oct6.203732.12847@acd4.UUCP> <125974@sun.Eng.Sun.COM> Reply-To: mjb@acd4.UUCP ( Mike Bryan ) Distribution: na Organization: Applied Computing Devices, Inc., Terre Haute, IN Lines: 79 In article <125974@sun.Eng.Sun.COM> beepy%commuter@Sun.COM (Brian Pawlowski) writes: > > [Info about data inconsistencies on NFS clients caused by attribute > caching deleted.] > >I'm curious what the application was that you had to abandon using NFS, >and what the systems were. > > ... > >Not to be a pain, but it's not so much a "problem" as a implementation >behaviour. Hmmm, hate to disagree with you, but it is a problem. Agreed, it is caused by implementation behaviour, but I think that that behaviour is wrong in some cases. It works fine 99.9% of the time, but in some cases, full UNIX semantics are just plain necessary. I like hearing about the availability of turning off attribute cacheing at a mount point. Now I just have to wait 32.7 years for DEC to absorb that code into Ultrix. :-) As for the exact reason we couldn't use NFS, I'll try to give a brief non-proprietary description. There are two processes, "A" and "B". Process A is receiving data, and putting it into a file. On some types of data, it will send a message to process B, telling it there is data available. Process B then reads the data from the file. If everything is on a single machine, there is no problem. The problem is when they are on different machines (process A on the NFS server, process B on the NFS client). Then process B gets the message, and goes to read the file. If it had been read "recently", as is often the case, the client will not have the updated data. Since NFS could not be relied on, our solution was to pass the necessary data with the message. Whether or not this is a preferred method is irrelevent. If NFS had supported full UNIX semantics, we could have expanded our system without a code change. As it was, we had to change our programs to handle the network case. As I said before, NFS locking was not available. Perhaps the "new" feature of turning off the attribute cache could be used to our benifit here... it sure would be nice. As a side note, we also investigated a product called FreedomNet, from RTI. It did support full UNIX semantics, including reading from character and block devices. It is a "stateful" architecture, as opposed to the "stateless" NFS. FreedomNet also supplied a lot of other neat features for distributed systems. Its drawbacks were a slight performance degradation, a few minor bugs in the version we had, and the price. We finally decided it was too expensive for our purposes, and we don't use it either. I personally feel it is a nice package however, and if a site can afford it (a few thousand dollars), they should investigate it. >Think about it: I typically work on my own files, in my >own area, and when I share files for program development, I use SCCS >to synchronize access and manage the software. Many files accessed >through NFS are read-only (shared executables). Locking is available >in the case requiring synchronization and tight consistency. Well, I don't see how SCCS can help you get around the NFS problem. Also, locking is not always possible. For starters, Ultrix 2.3 did not support it. Not to mention the fact (but I will anyway) that you cannot always use locking, especially when using pre-supplied system utilities (such as formatting a file and then reading/printing the formatted file on another client). The ability to turn off cacheing at a mount point is a good idea, however, and might be just what we need. On a more positive note, we *do* use NFS internally very heavily for our development systems. We have a network of five VAXen, each of which is an NFS server to the other four. Through a judicious sprinkling of symbolic links, a user can log into any of the machines and still see the same files. NFS works great for us in this respect. (Except for access to character/block devices... oh well :-( ) -- Mike Bryan, Applied Computing Devices, 100 N Campus Dr, Terre Haute IN 47802 Phone: 812/232-6051 FAX: 812/231-5280 Home: 812/232-0815 UUCP: uunet!acd4!mjb ARPA: mjb%acd4@uunet.uu.net "Did you make mankind after we made you?" --- XTC, "Dear God"