mike@ivory.SanDiego.NCR.COM (Michael Lodman) (03/23/88)
Could someone please summarize for me the differences and similarities
between RFS and NFS? Although I am somewhat familiar with NFS, I
know absolutely nothing about RFS.
--
Michael Lodman (619) 485-3335
Advanced Development NCR Corporation E&M San Diego
mike.lodman@ivory.SanDiego.NCR.COM
{sdcsvax,cbatt,dcdwest,nosc.ARPA,ihnp4}!ncr-sd!ivory!mike
When you die, if you've been very, very good, you'll go to ... Montana.jk@Apple.COM (John Kullmann) (03/24/88)
The key difference between NFS and RFS is: Everyone wants and uses NFS and no one wants or uses RFS. -- John Kullmann Apple Computer Inc. Voice: 408-973-2939 Fax: 408-973-6489
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/24/88)
In article <7765@apple.Apple.Com> jk@apple.UUCP (John Kullmann) writes: >The key difference between NFS and RFS is: > Everyone wants and uses NFS and no one wants or uses RFS. Funny, I thought the difference was that RFS is NFS done right. NFS has a decisive marketing head start, but technically it has several problems, the worst among them being UID mapping (yellow pages). I don't like the lock/stat daemons but presumably they at least work; the UID mapping is too restrictive (confined to a single subnet, requiring user-mode library changes, etc.).
lm@arizona.edu (Larry McVoy) (03/24/88)
In article <7765@apple.Apple.Com> jk@apple.UUCP (John Kullmann) writes: >The key difference between NFS and RFS is: > Everyone wants and uses NFS and no one wants or uses RFS. I suspect you'll get flamed for this but I'll back you up to this extent: In a recent V.3 port to some big iron the powers that be spent about 5 minutes deciding to dump RFS and add TCP/IP and NFS. I think it was mainly a compatibility decision. Note that I don't necessarily mean to condone NFS (I was looking at IS' TRFS [transparent remote file system] and it seems like they get better performance than NFS). And there is this business of "NFS is stateless so we'll add the stateful part in daemons off to the side". That's a little weird, but it _is_ a hard problem. -- Larry McVoy lm@arizona.edu or ...!{uwvax,sun}!arizona.edu!lm
roy@phri.UUCP (Roy Smith) (03/24/88)
jk@apple.UUCP (John Kullmann) writes: > Everyone wants and uses NFS and no one wants or uses RFS. To which gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) responds: > Funny, I thought the difference was that RFS is NFS done right. From what I hear and understand, both statements are exactly right. Yes, NFS has its faults (not to mention the Yellow Pages, which is even worse). Many is the time I wished I could just do "tar f /system/dev/mt0" instead of having to deal with rmt. Nevertheless, I make NFS a requirement on any system I spec. It works well enough for me (which means I don't get bent out of shape over the details of Unix file system semantics) and it seems to be near-universal. I can get NFS on everything from IBM-PCs to Alliant FX/8s, with lots of stuff in the middle (for all I know, it may even run on Crays, but I can't get Crays). Until I see RFS being that ubiquitious, I'll continue to spec NFS. On the other hand, I don't see any reason why vendors shouldn't support both NFS and RFS (just like they support X and NeWS, TCP/IP and ISO, Coke and Pepsi, etc). -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) (03/24/88)
In article <7533@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: |Funny, I thought the difference was that RFS is NFS done right. RFS allows access to remote devices, NFS does not. NFS is stateless. RFS is statefull. This might not seem like much, but if an RFS disk is mounted on 100 machines, and the server crashes and reboots, ....... Well, it just gets very messy. If an NFS server reboots, the clients just waits and then continue on. -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
rob@sun.soe.clarkson.edu (Rob Logan) (03/24/88)
From article <3211@phri.UUCP>, by roy@phri.UUCP (Roy Smith): > jk@apple.UUCP (John Kullmann) writes: >> Everyone wants and uses NFS and no one wants or uses RFS. > > To which gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) responds: >> Funny, I thought the difference was that RFS is NFS done right. I think the point is rather mute when you consider System V.4 is shipping with NFS. Rob rob@sun.soe.clarkson.edu
zdenko@csd4.milw.wisc.edu (Zdenko Tomasic) (03/24/88)
In article <616@sun.soe.clarkson.edu> rob@sun.soe.clarkson.edu (Rob Logan) writes: >From article <3211@phri.UUCP>, by roy@phri.UUCP (Roy Smith): >> jk@apple.UUCP (John Kullmann) writes: >>> Everyone wants and uses NFS and no one wants or uses RFS. >> >> To which gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) responds: >>> Funny, I thought the difference was that RFS is NFS done right. > >I think the point is rather mute when you consider System V.4 ^^^^^^^^^^ >is shipping with NFS. ^^^^^^^^^^^ right now? > > Rob > >rob@sun.soe.clarkson.edu Zdenko Tomasic UWM, Chem. Dept. Milwaukee,WI,53201 __________________________________________________________ UUCP: ihnp4!uwmcsd1!csd4.milw.wisc.edu!zdenko ARPA: zdenko@csd4.milw.wisc.edu __________________________________________________________
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/25/88)
In article <4477@megaron.arizona.edu> lm@megaron.arizona.edu (Larry McVoy) writes: >minutes deciding to dump RFS and add TCP/IP and NFS. I think it was >mainly a compatibility decision. It is clearly a marketing decision. Widely-used existing "standards" are in demand and others generally are not. We have some RFS and Starlan-compatible systems here, but since the rest of our network is built around NFS and TCP/IP and does not know how to support RFS or Starlan, we obviously don't use them. (By the way, I don't know if Starlan is techincally worth using, but RFS would be.) For similar reasons we're not using ISO TP4, X.25, and other possibly worthwhile facilities. I must say that removing RFS from a UNIX System V Release 3 port is a serious mistake; adding TCP/IP and NFS is perfectly reasonable.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/25/88)
In article <616@sun.soe.clarkson.edu> rob@sun.soe.clarkson.edu (Rob Logan) writes: >I think the point is rather mute when you consider System V.4 >is shipping with NFS. I didn't know that SVR4 is shipping at all yet, but I can believe that it will include NFS support. This doesn't mean that NFS would be a better choice than RFS in all circumstances (only if interoperability with other NFS systems that lack RFS support is necessary). I would hope that RFS is also continued in SVR4. Better yet would be for Sun to fix NFS so that the interface looks the same but the internals use much of the same implementation approach as RFS.
sample@chimay.cs.ubc.ca (Rick Sample) (03/25/88)
In article <7533@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >I don't like the lock/stat daemons but presumably they >at least work; My experience is that they work marginally, at best. rpc.lockd is prone to growing very large and then dropping a huge core file in /core. Sun claims that the 3.5 version is fixed. The 3.5 lockd is better than the 3.2 lockd (it lasted about 12 hours before dying in our environment) but is still not fixed. I have a mostly fixed version of lockd, but I can't distribute it, of course. I think that the reason there hasn't been more complaint about lockd is that very little use is made of it in a standard Sun environment. We run a locally developed X.400 message system as our standard mail system, and it makes extensive use of the lock daemon. When the lock daemon dies (as it did very frequently before I modified it) the mail programs hang and cannot be killed, causing much frustration to the unsuspecting user. There were numerous obvious bugs in the rpc.lockd code, many could be found just by running lint. I sent some of my fixes to Sun, but I don't think they made it into the 3.5 release. I don't have 3.5 source code yet so I can't be sure. Rick Sample, Facilities Manager, UBC Computer Science
bzs@bu-cs.BU.EDU (Barry Shein) (03/25/88)
From Doug Gwyn >In article <7765@apple.Apple.Com> jk@apple.UUCP (John Kullmann) writes: >>The key difference between NFS and RFS is: >> Everyone wants and uses NFS and no one wants or uses RFS. > >Funny, I thought the difference was that RFS is NFS done right. > >NFS has a decisive marketing head start, but technically it has >several problems, the worst among them being UID mapping (yellow >pages). I don't like the lock/stat daemons but presumably they >at least work; the UID mapping is too restrictive (confined to >a single subnet, requiring user-mode library changes, etc.). I don't disagree with your criticisms Doug, they're valid and true (not that they always cause problems, but when they do it's a big problem.) I know Sun has committed to fixing these things (there was a USENIX paper in Phoenix by some Sun folks presenting a possible design, I don't remember if general agreement was that the design was viable, but I do believe that, just like the lock/stat daemons, they're committed to solutions and recognize the problem, I believe SunOS4.0 due out "real soon now" will address the UID problem, I could be wrong.) I just heard a presentation from ANOTHER [very big] vendor on their *own* distributed file system they were going to push instead of NFS (tho they would support NFS, I guess, there were some tricky if/ands/buts, all nodes equal but some nodes MORE equal sort of logic.) Actually they were presenting two, mutually incompatible, distributed file systems, plus NFS. What's the expression? The great thing about standards is that there are so many to choose from... I honestly and sincerely believe that at this point in time, with the ubiquitousness of NFS, efforts by vendors would be far better spent bashing Sun to hurry up these pieces they need, or even figuring out COMPATIBLE ways to provide them as value-added pieces of their own product (obviously that has to be done carefully), preferably feeding them back into the protocol standard. Otherwise I think all these vendors, all focusing on the same exact gripes with NFS, are just doomed to waste a lot of time and energy. Standards and compatibility have become far more important than nitpicking at bugs that could be fixed but instead coming out with something incompatible. Let's get on to something creative, not reinventing the wheel where a bug fix would do just as well. There really are other and better fish to fry. -Barry Shein, Boston University
bzs@bu-cs.BU.EDU (Barry Shein) (03/25/88)
>I think the point is rather mute when you consider System V.4 >is shipping with NFS. > > Rob Is that true?! Hooray! Another unnecessary difference resolved. Gee, maybe ATTIS is getting their act together :-) -Barry Shein, Boston University And what will we call it when it's all finally merged? Unix.
nessus@athena.mit.edu (Doug Alan) (03/25/88)
In article <616@sun.soe.clarkson.edu> rob@sun.soe.clarkson.edu (Rob Logan) writes: > I think the point is rather mute when you consider System V.4 > is shipping with NFS. The last I heard, System V.4 was going to support both RFS and NFS.... |>oug /\lan
lm@arizona.edu (Larry McVoy) (03/25/88)
In article <4112@vdsvax.steinmetz.ge.com> barnett@steinmetz.ge.com (Bruce G. Barnett) writes: >In article <7533@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >|Funny, I thought the difference was that RFS is NFS done right. > >RFS allows access to remote devices, NFS does not. > >NFS is stateless. RFS is statefull. This might not seem like much, >but if an RFS disk is mounted on 100 machines, and the server crashes >and reboots, ....... Well, it just gets very messy. Yeah, well, I've worked on Suns (NFS:"stateless") and Apollos (???:stateful), and quite frankly, I prefer the Apollo version, in principle, at least. Here's why: Although the performance of NFS is initially better (much better) it degrades very poorly, to the point of being unusable. The Apollo version starts out slow but seems to degrade linearly (or close to linearly) with pressure. Now, I don't know if the state-less/ful aspects of the designs had anything to do with this, but I suspect it comes into play. And a further comment on stateless file systems: when working on the Apollos, it was rarely, if ever the sort of disaster envisioned by the stateless advocates when a node crashed. I dunno how, but somehow or other things seemed to work ok. You noticed that certain trees of files were "gone". That's all. Nothing worse. -- Larry McVoy lm@arizona.edu or ...!{uwvax,sun}!arizona.edu!lm
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/25/88)
In article <4112@vdsvax.steinmetz.ge.com> barnett@steinmetz.ge.com (Bruce G. Barnett) writes: >In article <7533@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >|Funny, I thought the difference was that RFS is NFS done right. >RFS allows access to remote devices, NFS does not. Right, among other aspects of transparency. >NFS is stateless. RFS is statefull. This might not seem like much, >but if an RFS disk is mounted on 100 machines, and the server crashes >and reboots, ....... Well, it just gets very messy. I don't think so. The crash does not go undetected; an attempt to access a remote file while the link is down returns an immediate error, and when the link comes back up the RFS subsystem straightens out the bookkeeping. I forget the details but I once knew them and they seemed right to me. >If an NFS server reboots, the clients just waits and then continue on. Typically an attempt to access a file on a down link causes the process to BLOCK at UNINTERRUPTIBLE priority! I have been quite pissed off at this, on more than one occasion. It's great fun to type "df" and then find that you're never going to get any farther...
pjh@mccc.UUCP (Peter J. Holsberg) (03/25/88)
In article <7539@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: |I must say that removing RFS from a UNIX System V Release 3 port is |a serious mistake; adding TCP/IP and NFS is perfectly reasonable. Is it possible to add TCP and Ethernet to a 3B2/400 running SysV r3.0 v2?? -- Peter Holsberg UUCP: {rutgers!}princeton!mccc!pjh Technology Division CompuServe: 70240,334 Mercer College GEnie: PJHOLSBERG Trenton, NJ 08690 Voice: 1-609-586-4800
davidsen@steinmetz.steinmetz.ge.com (William E. Davidsen Jr) (03/26/88)
In article <4112@vdsvax.steinmetz.ge.com> barnett@steinmetz.ge.com (Bruce G. Barnett) writes: | [...] | NFS is stateless. RFS is statefull. This might not seem like much, | but if an RFS disk is mounted on 100 machines, and the server crashes | and reboots, ....... Well, it just gets very messy. | | If an NFS server reboots, the clients just waits and then continue on. I think this is a case of apples and oranges... NFS clearly is faster than RFS at this time because of stateless operation and caching. RFS knows about opens and locks and stuff, ideal for operation when geting it right is better than getting it fast. I think that NFS has minimal problems when used to share files for read only (which is a lot of what we do here) and single user access. I would be much more confident that RFS wouldn't bite me if I were running a database application. I think there are times when you need to know that the server has gone away, to be positive that the locks are locked and the data is/isn't current. I know that people are running database access through RPCs with a single server process, but the need to do that somewhat proves my point. Each method has its advantages, and people should understand them. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
karish@denali.UUCP (karish) (03/26/88)
In article <7544@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <4112@vdsvax.steinmetz.ge.com> barnett@steinmetz.ge.com (Bruce G. Barnett) writes: > >Typically an attempt to access a file on a down link causes the process >to BLOCK at UNINTERRUPTIBLE priority! I have been quite pissed off at >this, on more than one occasion. It's great fun to type "df" and then >find that you're never going to get any farther... When I've tried this, the attempt to read from an inaccessible NFS partition has timed out after two minutes (on a VAX running SULTRIX). Chuck
jk@Apple.COM (John Kullmann) (03/26/88)
In article <7533@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <7765@apple.Apple.Com> jk@apple.UUCP (John Kullmann) writes: >>The key difference between NFS and RFS is: >> Everyone wants and uses NFS and no one wants or uses RFS. > >Funny, I thought the difference was that RFS is NFS done right. Sorry Doug, 'rightness' does not enter into it. We got RFS working at Opus Systems, proudly demo'd it to all our key customers, etc. etc., and every single one of them said "gee, that's nice. when can I get NFS...". I have heard this story from others too. In the thousands and thousands of systems shipped not a single customer wanted RFS. By the way, I happen to agree with your points about UID probs, etc. and could throw in a few of my own, like remote device access but I still think that it doesnt matter how neat, functionally correct, etc. etc. something is if no one wants it. disclaimer: I am no longer at Opus Systems and nothing I might or might not say can be attributed to anyone but myself. so there! -- John Kullmann Apple Computer Inc. Voice: 408-973-2939 Fax: 408-973-6489
robert@setting.weitek.UUCP (Robert Plamondon) (03/26/88)
In article <4496@megaron.arizona.edu> lm@megaron.arizona.edu.UUCP (Larry McVoy) writes: >And a further comment on stateless file systems: when working on the >Apollos, it was rarely, if ever the sort of disaster envisioned by the >stateless advocates when a node crashed. I dunno how, but somehow or >other things seemed to work ok. You noticed that certain trees of >files were "gone". That's all. Nothing worse. To me, NOTHING is worse than losing files due to a server crash! The server can burst into flames and slag down on the computer floor for all I care, just so long as somewhere in the smoking mass of ex-hardware is a disk drive that still has my work on it. Hardware comes and goes, operating systems can be reloaded, but the user's work is all-important! -- Robert -- Robert Plamondon UUCP: {pyramid,cae780}!weitek!robert ARPA: "pyramid!weitek!robert"@decwrl.dec.COM "The paper IS the product"
jk@Apple.COM (John Kullmann) (03/26/88)
In article <616@sun.soe.clarkson.edu> rob@sun.soe.clarkson.edu (Rob Logan) writes: > >I think the point is rather mute when you consider System V.4 >is shipping with NFS. Oh please! Give me a break. First, unless you are among the chosen few to actually be on the inside for V.4 or you can guarantee your statement please don't tell me about what V.4 is. Next, based on their past performance, if AT&T is involved I just don't believe V.4 will be 'out' for 'a long time.' Some of us have to worry about products we can/are ship(ing) today. Also, even if V.4 has NFS it stilll doesnt change the fact that no one is using RFS. These are my opinions, flame me, I couldn't care less. -- John Kullmann Apple Computer Inc. Voice: 408-973-2939 Fax: 408-973-6489
fdr@joy.ksr.com (Franklin Reynolds) (03/26/88)
NFS has one significant advantage over RFS - it runs on lots of different machines. This is important. However, RFS (at least the specification of RFS) is technically superior to NFS. 1. Unix file system semantics are preserved. This means things like record locking and remote device access as well as simple things open(), write(), unlink() work the way you would like them to work. 2. The remote UID mapping stuff that NFS does is basically useless. Remote superusers can impersonate anyone they want which allows them to circumvent the NFS restrictions. RFS allows you to controll *all* remote accesses. 3. NFS does not provide you with any way to have a location indepentent view of the distributed file system. There is Yellow Pages but they are best described as a small band-aid applied to a gaping wound. RFS has a name server that seems to do a better job. NFS seems obsolete to me. It was ok (though just barely) when it was introduced but it hasn't kept up with technology. These days we should be able to have honest-to-gosh transparently networked file systems. All this stuff about stateless file sytems being nice and besides stateful file systems are hard is hooey. If other people can do it, then Sun should be able to. Franklin Reynolds fdr@ksr.uucp ksr!fdr@harvard.harvard.edu harvard!ksr!fdr Kendall Square Research Corporation Building 300 / Hampshire Street One Kendall Square Cambridge, Ma 02139
roy@phri.UUCP (Roy Smith) (03/26/88)
gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: > >If an NFS server reboots, the clients just waits and then continue on. > > Typically an attempt to access a file on a down link causes the process > to BLOCK at UNINTERRUPTIBLE priority! You must be using an oldish version of NFS; I think this is the way it worked in SunOS-3.0, with 3.2 and later, you have the option of soft mounting a file system, which lets NFS operations time out. Since this is bad for r/w file system and overloaded-but-not-dead-yet servers, you can also mount file systems hard, but with the "intr" option which never times out on its own, but does allow the process to be killed (I guess it sleeps with a low, but non-negative priority) -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
lm@arizona.edu (Larry McVoy) (03/26/88)
In article <649@setting.weitek.UUCP> robert@setting.weitek.UUCP (Robert Plamondon) writes: >In article <4496@megaron.arizona.edu> I wrote: >>other things seemed to work ok. You noticed that certain trees of >>files were "gone". That's all. Nothing worse. > >To me, NOTHING is worse than losing files due to a server crash! The You misunderstood. Gone is in quotes for a reason; perhaps I should have said "unavailable". I have yet to lose a file or changes to a file under the apollo system. -- Larry McVoy lm@arizona.edu or ...!{uwvax,sun}!arizona.edu!lm
davy@ea.ecn.purdue.edu (Dave Curry) (03/26/88)
In article <7544@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >>If an NFS server reboots, the clients just waits and then continue on. > >Typically an attempt to access a file on a down link causes the process >to BLOCK at UNINTERRUPTIBLE priority! I have been quite pissed off at >this, on more than one occasion. It's great fun to type "df" and then >find that you're never going to get any farther... So mount your file systems "hard,intr" and you can interrupt out of things. Granted this is not a whole lot better, but you can at least get your workstation back. Better yet, if you have the file system mounted for read-only purposes and seldom actually write anything to it (e.g. other servers' file systems), then mount them "soft", and the problem goes away. The biggest brain damage with NFS in this regard comes in a situation like, say, you have /usr/server1, /usr/server2, and /usr/server3 mounted "hard", and you serve off server1. Then even if server3 goes down, you're screwed the first time namei() is called -- it hangs on the down server's file system. So, some server you hardly ever give a damn about goes down, and you can't execute any commands until it comes up. Yuck. Sun 4.0 supposedly fixes this by having "mount on reference" file systems. The release date for Sun 4.0 is May 19 or thereabouts. Somehow I think this discussion is never going to get anywhere... there are lots of valid reasons for stateless servers, and lots of other valid reasons for stateful servers. The problem is that each method solves the deficiencies in the other - neither approach solves all the problems. --Dave Curry Purdue University Engineering Computer Network
jfc@athena.mit.edu (John F Carr) (03/26/88)
In article <25@denali.UUCP> karish@denali.UUCP (Chuck Karish) writes: >In article <7544@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >>In article <4112@vdsvax.steinmetz.ge.com> barnett@steinmetz.ge.com (Bruce G. Barnett) writes: ::Typically an attempt to access a file on a down link causes the process ::to BLOCK at UNINTERRUPTIBLE priority! I have been quite pissed off at ::this, on more than one occasion. It's great fun to type "df" and then ::find that you're never going to get any farther... :When I've tried this, the attempt to read from an inaccessible NFS :partition has timed out after two minutes (on a VAX running SULTRIX). I've seen both results. On one occasion, when the link went down, processes trying to use the link hung forever, waiting for the data which never arrived... The present result (with newer software which has probably been considerably modified by MIT's project Athena) when a server goes down is a timeout and error message. John Carr "No one wants to make a terrible choice jfc@athena.mit.edu On the price of being free" -- Neil Peart
bzs@bu-cs.BU.EDU (Barry Shein) (03/26/88)
Doug Gwyn replying to someone >>If an NFS server reboots, the clients just waits and then continue on. > >Typically an attempt to access a file on a down link causes the process >to BLOCK at UNINTERRUPTIBLE priority! I have been quite pissed off at >this, on more than one occasion. It's great fun to type "df" and then >find that you're never going to get any farther... No doubt I won't be the only person to point out that this is all now settable in fstab, you can distinguish hard (hang on failure), soft (error on failure) and intr (allow interrupts), it's become just a system admin issue (some of those options were not available w/ previous releases so you used to be right, like I said, let's get it fixed and get on with other things.) -Barry Shein, Boston University
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/26/88)
In article <3215@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >> Typically an attempt to access a file on a down link causes the process >> to BLOCK at UNINTERRUPTIBLE priority! > You must be using an oldish version of NFS; I think this is the way >it worked in SunOS-3.0, with 3.2 and later, ... Sounds like Sun is working on the problems, which is good. By the way, my hung "df" occurred on a Gould UTX-32 system, not on a Sun, although the down fileserver may have been a Sun (with the system wedging every time I touched the filesystem, it was hard to tell). Perhaps one or both of the workarounds you mentioned was available and the system administrator had made a mistake. (Not my system!)
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/26/88)
In article <275@ksr.UUCP> fdr@ksr.UUCP (Franklin Reynolds) writes: >NFS seems obsolete to me. It was ok (though just barely) when >it was introduced but it hasn't kept up with technology. I agree with your comments, but to be fair it should be noted that one of the explicit design goals of NFS was to work not only with UNIX filesystems but also with MS-DOS filesystems. (Apparently somebody thought there was money to be extracted from the IBM PC fad.) I don't know if NFS was actually much used with MS-DOS. I do know that being first and making it easy to license the technology was instrumental in Sun's NFS success. I wonder if anyone in AT&T who controls product planning learned a lesson from that? There have been numerous nifty AT&T products, technically superior to competitive products, that have pretty much failed in the marketplace due to taking too long to become available and then not being marketed well. I won't recount the list here; you probably know of some of these products. (AT&T isn't alone here, but I pick on them because of my frustration at not being able to build applications on software technology that I know could have been available if only...)
robert@pyr.gatech.EDU (Robert Viduya) (03/27/88)
>fdr@ksr.UUCP (Franklin Reynolds) (fdr@ksr.UUCP, <275@ksr.UUCP>): > ... All this stuff about stateless file sytems being > nice and besides stateful file systems are hard is hooey. If other > people can do it, then Sun should be able to. Hear, hear. NFS strikes me as being something that was designed to be easier for programmers to implement AT THE EXPENSE OF THE USERS. The attitude of the proponents of state-less-ness back this up. Most, if not all of thier pro (as opposed to con) arguments for NFS are technical in nature and are things that only a developer would have to deal with. The user gets short-changed by occasionally having to be aware that his file exists on a remote machine. Having used both RFS and NFS, I, and a number of other people around here much prefer RFS for it's transparency. None of the semantics of Unix files are lost. Unfortunately, it's limited degree of availability has forced us into the NFS world. robert -- Robert Viduya robert@pyr.gatech.edu Office of Computing Services Georgia Institute of Technology (404) 894-6296 Atlanta, Georgia 30332-0275
ekrell@hector.UUCP (Eduardo Krell) (03/27/88)
In article <7765@apple.Apple.Com> jk@apple.UUCP (John Kullmann) writes: >The key difference between NFS and RFS is: > Everyone wants and uses NFS and no one wants or uses RFS. I thought the key difference was that RFS maintains true Unix semantics when the file is remote. NFS does not (locks, for instance). Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {ihnp4,ucbvax}!ulysses!ekrell ARPA: ekrell@ulysses.att.com
mash@mips.COM (John Mashey) (03/27/88)
I suggest that this discussion doesn't particularly belong in comp.arch.
Please note that it is included in comp.unix.wizards, where it properly belongs.
--
-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com
DDD: 408-991-0253 or 408-720-1700, x253
USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086les@chinet.UUCP (Leslie Mikesell) (03/27/88)
In article <7556@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >I agree with your comments, but to be fair it should be noted >that one of the explicit design goals of NFS was to work not >only with UNIX filesystems but also with MS-DOS filesystems. AT&T sells a DOS server product for the 3B line that provides netbios compatible file and print services to PC's connected via the Starlan network. The unix semantics are not completely preserved (for examples FIFOs are not visible from DOS) but when a unix home directory is shared by the dos server the ownership of the files is maintained properly (even though the dos machine doesn't understand this). Password checking is done to establish the link, of course, and a program is available that allows execution of unix commands from the dos command line with permissions based on the id associated with the connected home directory. It is possible to to pipe data between dos and unix programs. If remote unix directory is mounted via RFS into a directory shared by the DOS server, the files appear in the expected location (even though it takes two hops over the net to get there). Some munging of the unix filenames is done to produce unique names that dos will accept, otherwise the files look the same from either os. I am currently involved in setting up an office with about 30 PC's (expected to be around 80 by the end of the year) with all of the file storage and shared printers on unix machines. Access is not blazingly fast but certainly acceptable (seems like about 1/2 local hd speed on the average). The only real deficiency I can see so far is that there is no way for the unix machine to initiate contact with a PC, for example to give a notification of mail or use a printer connected to a PC. -Les Mikesell ...ihnp4!chinet!les
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/27/88)
In article <10184@ulysses.homer.nj.att.com> ekrell@hector (Eduardo Krell) writes: >I thought the key difference was that RFS maintains true Unix >semantics when the file is remote. NFS does not (locks, for >instance). In some implementations, at least, there is a separate "lock daemon" process that receives locking/unlocking requests on a socket and coordinates access to the files. I know, it's a kludge, but it ought to be able to work right (somebody did report problems with theirs).
stpeters@dawn.steinmetz (Dick St.Peters) (03/28/88)
In article <20915@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: [stuff about SysV.4 shipping with NFS] >And what will we call it when it's all finally merged? Unix. "I have no idea what will be the most important language twenty years from now, but whatever it is, it will be called Fortran." - an old-timer[1], about ten years ago. [1] old-timer: anyone who had started programming by 1954. -- Dick St.Peters GE Corporate R&D, Schenectady, NY stpeters@ge-crd.arpa uunet!steinmetz!stpeters -- Dick St.Peters GE Corporate R&D, Schenectady, NY stpeters@ge-crd.arpa uunet!steinmetz!stpeters
reggie@pdn.UUCP (George W. Leach) (03/29/88)
In article <7556@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >I wonder if anyone in AT&T who controls product >planning learned a lesson from that? I doubt it. The culture at AT&T (as opposed to BTL) probably hasn't changed enough since 1/1/84 to allow for such *advanced* thought :-) >AT&T isn't alone here, but I pick on them because of my frustration at >not being able to build applications on software technology >that I know could have been available if only... So thats what those guys in the HP commercials are thinking about :-) "What If......AT&T hadn't screwed it up" But seriously, I agree!!! (who couldn't?) It must be damn frustrating for some of the folks at the Labs to see thier fine work go down the tubes due to lack of marketing expertise and infighting due to politics in the product development stages. Remember BTL does the research and someone else re-implements those ideas as a product. Too bad that v8 (or now v9) was not in a form to be released to the world. -- George W. Leach Paradyne Corporation {gatech,rutgers,attmail}!codas!pdn!reggie Mail stop LF-207 Phone: (813) 530-2376 P.O. Box 2826 Largo, FL 34649-2826
gerry@syntron.UUCP (G. Roderick Singleton) (03/31/88)
In article <649@setting.weitek.UUCP> robert@setting.weitek.UUCP (Robert Plamondon) writes: >In article <4496@megaron.arizona.edu> lm@megaron.arizona.edu.UUCP (Larry McVoy) writes: >>And a further comment on stateless file systems: when working on the >>Apollos, it was rarely, if ever the sort of disaster envisioned by the >>stateless advocates when a node crashed. I dunno how, but somehow or >>other things seemed to work ok. You noticed that certain trees of >>files were "gone". That's all. Nothing worse. > >To me, NOTHING is worse than losing files due to a server crash! The >server can burst into flames and slag down on the computer floor for >all I care, just so long as somewhere in the smoking mass of >ex-hardware is a disk drive that still has my work on it. Hardware >comes and goes, operating systems can be reloaded, but the user's work is >all-important! They DON'T disappear, they just become unavailable while things sort themselves out. One important thing about RFS that none has mentioned yet is that it's important to remember during configuration that you don't put all your eggs in one basket. That is, don't expect things to work if you have all the root partitions mounted on the same filesystem. I know, I know a pretty extreme example BUT it's so easy to do that you can do this to important stuff and then grind to a halt as the result of the sourcing node crashing. SOOO, losing anything comes back to the user saving his stuff regularly, et cetera which reduces the risk to almost that of any single node. -- G. Roderick Singleton, Technical Services Manager { syntron | geac | eclectic }!gerry "ALL animals are created equal, BUT some animals are MORE equal than others." George Orwell
beres@cadnetix.COM (Tim Beres) (03/31/88)
In article <7544@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >It's great fun to type "df" and then >find that you're never going to get any farther... First thing I learned coming to our BSD/NFS environment was to always type: $ df& You may not get your answer, but at least you can go onward. -- Tim Beres Cadnetix 303/444-8075 x221 5775 Flatirons Pkwy {uunet,boulder,nbires}!cadnetix!beres Boulder, CO 80301 beres@cadnetix.com <disclaimers: my thoughts != Cadnetix's>
rmb384@leah.Albany.Edu (Robert Bownes) (04/03/88)
In article <7556@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > In article <275@ksr.UUCP> fdr@ksr.UUCP (Franklin Reynolds) writes: > >NFS seems obsolete to me. It was ok (though just barely) when > >it was introduced but it hasn't kept up with technology. > > I agree with your comments, but to be fair it should be noted > that one of the explicit design goals of NFS was to work not > only with UNIX filesystems but also with MS-DOS filesystems. > (Apparently somebody thought there was money to be extracted > from the IBM PC fad.) I don't know if NFS was actually much > used with MS-DOS. I do know that being first and making it NFS was designed to be OS independant. If I may be so bold as to quote from the paper originally written about NFS, it is intended for "A heterogeneous OS environment" and "Should be easily extensible, should only implement protocol not dependant on the OS". When I first went to work for Sun, we put together a multivendor testing session in which we had machines running 5 different OS's all running NFS and sharing files. One of them was VMS, one was MS-DOS and PC-NFS, one other I don't remember, and two unix variants. It was kinda neat to see the PC/AT having an Eagle as drive G: and running SPICE off a database on the uVAX across the room.... Bob Bownes Note: Yes, I work for SUN when I'm not pursuing a lower education. I am also a SUN stockholder. -- Bob Bownes, Aka Keptin Comrade Dr Bobwrench III | If I didn't say it, It bownesrm@beowulf.uucp (518)-482-8798 | must be true. {steinmetz,brspyr1,sun!sunbow}!beowulf!bownesrm | - me, tonite -
barmar@think.COM (Barry Margolin) (04/04/88)
In article <676@leah.Albany.Edu> rmb384@leah.Albany.Edu (Robert Bownes) writes: > NFS was designed to be OS independant. If I may be so bold as to quote >from the paper originally written about NFS, it is intended for >"A heterogeneous OS environment" and "Should be easily extensible, should >only implement protocol not dependant on the OS". While NFS is an admirable protocol, it falls a bit short in totally reaching those goals. For example, for most things NFS doesn't require the client machine to parse the server's pathnames, so instead the client traverses the client's hierarchy. However, the operation that reads a symbolic link returns a pathname string in the server's format. Chris Lindblad, of the MIT AI Lab, and Mark Son-Bell, of International Lisp Associates, the authors of ILA-NFS, an implementation of NFS for Symbolics Lisp Machines, wrote a paper describing the OS-independence issues they encountered while writing it. I'm not sure whether it has been published (they include it in their user manual); CJL@REAGAN.AI.MIT.EDU should be able to tell you how to get a copy (I hope he doesn't mind me dropping his name without permission). Barry Margolin Thinking Machines Corp. barmar@think.com uunet!think!barmar
zs01+@andrew.cmu.edu (Zalman Stern) (04/08/88)
> Bunch of stuff about how stateful filesystems crash and burn when a server
crash.
Here at CMU (the Andrew project) we use the Andrew Filesystem (AFS). (Known as
"VICE" to its friends.) This is a very stateful filesystem and provides very
good performance under high load conditions. (Most of our servers are have
about 100 active clients at a time.) This is of course due to local disk
caching. When a server goes down, you cannot access any files on that server.
You get a message on the console saying that server such and such is down, and
all file access to that server return ETIMEDOUT. When the server comes back up,
everything returns to normal. I hardly call this "messy."
From what I understand about NFS, it becomes flakey under adverse network
conditions or high server load. For example, one benchmark we ran tried to put
20 clients on an NFS server. The benchmark would attempt to do a mkdir system
call (for a directory that did not exist) and get back an EEXIST error. What
happened was the server got the mkdir request packet and sent a response
indicating success. The response got dropped, so after a while the client
retried the initial request. This time, the mkdir request hit the server and
the directory had already been made by the first request. So the server sent
back an error return. I suppose this is a consequence of mkdir not being
idempotent. If this is a bug, fine. On the other hand, if it is a property of
stateless remote filesystems, they should be nuked til they glow.
Finally, a request for info. We are currently testing a new mechanism to handle
UID -> name mapping for separately administered shared filesystems. (That is,
users on machine A want to look at files on machine B but don't want to see B's
UIDs translated to A's names...) Someone mentioned that RFS gets this right. I
would appreciate it if someone could send me mail summarizing how this works in
RFS.
Sincerely,
Zalman Stern
Internet: zs01+@andrew.cmu.edu Usenet: I'm soooo confused...
Information Technology Center, Carnegie Mellon, Pittsburgh, PA 15213-3890geoff@eagle_snax.UUCP ( R.H. coast near the top) (04/12/88)
In article <7556@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > ... one of the explicit design goals of NFS was to work not > only with UNIX filesystems but also with MS-DOS filesystems. And a few other popular beasts like VAX/VMS, Crays, mainframes, not to mention Macs, Amigas.... > (Apparently somebody thought there was money to be extracted > from the IBM PC fad.) I don't know if NFS was actually much > used with MS-DOS. Well, PC-NFS is now up to release 3 with sales in five figures. [I don't think I'm supposed to give the actual number.] -- Geoff Arnold, Sun Microsystems | "Universes are just one of those things SPD at ECD (home of PC-NFS) | that happen from time to time..." UUCP:{ihnp4,decwrl...}!sun!garnold | [Dunno who said it - if you know, pass it ARPA:garnold@sun.com | on. G.A.]
mouse@mcgill-vision.UUCP (der Mouse) (04/16/88)
In article <18745@think.UUCP>, barmar@think.COM (Barry Margolin) writes: > In article <676@leah.Albany.Edu> rmb384@leah.Albany.Edu (Robert Bownes) writes: >> NFS was designed to be OS independant. > While NFS is an admirable protocol, it falls a bit short in totally > reaching those goals. For example, for most things NFS doesn't > require the client machine to parse the server's pathnames, so > instead the client traverses the client's hierarchy. However, the > operation that reads a symbolic link returns a pathname string in the > server's format. Not necessarily; it depends on who created the link. If it was created by the client with the create-a-symlink NFS operation, the string the client finds when it reads the link should be identical to the string it stored there when it created it. When the client and server have different notions of pathnames, symlinks can't work on both at once (unless the server tries to be clever and mungs the path for the client, which defeats the goal of OS independence). (Of course, there is another point that should be (has been?) raised: sometimes you don't want an OS-independent protocol. Such as when speaking between two UNIX systems, when you presumably want full UNIX semantics, which NFS just can't support. NFS is great if you want Macintosh, VMS, UNIX, MS-DOS, Lisp Machine, Multics, etc all sharing files. But when you have just UNIX machines, it isn't the greatest.) der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu