Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!convex!thurlow From: thurlow@convex.com (Robert Thurlow) Newsgroups: comp.unix.internals Subject: Re: (was slashes, now NFS devices) Message-ID: Date: 17 Mar 91 03:07:59 GMT References: <1991Mar9.170841.4042@panix.uucp> Sender: news@convex.com (news access account) Organization: Convex Computer Corporation, Richardson, Tx. Lines: 80 Nntp-Posting-Host: dhostwo.convex.com More from David Zink: >I do the following command: >$ cat /bin/* > P1 & ; sleep 1 ; ls -l >The ls hangs until the cat finishes. No, it doesn't hang on our system, but it does take a long time. You're getting an awful lot of contention for the lock on that file, so the stat(2) is not going to be an instant thing. And guess what? This is exactly the way local disk works (try it, but scale up your data size accordingly). The only difference is the performance bottleneck due to the network. If you crippled your I/O subsystem, you'd see similar things. Until we get new networks that are two orders of magnitude faster, this may be the case. And even then, misdirected packets, lossy networks and dead servers are going to have to be dealt with. What people don't seem to realize until they work with this stuff a bit is that you're taking a kernel that assumes it has absolute dominion over a disk that will never fail and trying to make it understand that yes, the disk might not be exclusively yours, and yes, the disk might just never give you that block. This is a damned tough challenge to meet. Some problems can be addressed by changing the way things are done, but you're still up against a big brick wall in some areas. Thank _God_ NFS doesn't permit transparent access to remote devices; the assumptions there would make the disk I/O system assumptions look tame. [Open-unlink failures:] >They both open the same file (already a bug) and one unlinks it. Poof, >stale file handle. (I could as easily say the problem is the non-use of O_EXCL) Exactly. I hammer on Sun about this point - this lack is definitely a protocol bug that needs to be fixed, and if it only was, I think I could make my kernel Do The Right Thing in under a day. This is the thing that annoys me most about NFS. >And I wish you wise guys would stop telling me 'If you don't like it, write >better.' I have not the time, and I suspect that even if I did write one it >would never achieve much distribution due to the livable solutions already >in place. NFS cannot be all that I want until a partitioned kernel with redundancy and fault-tolerance comes along which is obviously the best direction for the majority to choose as its next Unix base (i.e., Unix System VII Release 69, based on both Mach and Chorus). Sun has something that works this century, and it basically lets us get work done we _could not_ do otherwise without great expense. Does it need improvement? Yes. Is it a pain in the butt at times? Yes. Do current implementations have bugs? Definitely. I am very interested in talking about those bugs and trying to fix them, and I get impatient with people who only want to bitch. Especially at those who I feel haven't done enough thinking about the issues. I am more compassionate about the problems of naive end users than I am about someone who has an insufficiently-researched great idea about how he'd do it, if he only had the time. >I have heard no argument in favor of NFS that did not have the same form >as the arguments I always hear in favor of Basic and Cobol. Don't use NFS. Just try to live without it. And when you do use it (because you'll have to sometimes), report the bugs you find so they can be fixed. >P.S. If NFS need hold no state on the server, what is a .nfsXXX file? >"I know, I know, it's not part of the protocol." Think: if the server crashes, the file will still be there. If the client crashes, the process that cared won't be running. The state has no impact on correctness in either case. NFS "statelessness" is not exactly what the marketing word implies; if a different word had been coined, you might be just as confused or moreso. I think that people who take the word "statelessness" at face value get the confusion they deserve. Rob T -- Rob Thurlow, thurlow@convex.com An employee and not a spokesman for Convex Computer Corp., Dallas, TX