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
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/26/88)
In article <512@mccc.UUCP> pjh@mccc.UUCP (Peter J. Holsberg) writes: >Is it possible to add TCP and Ethernet to a 3B2/400 running SysV r3.0 v2?? It must be possible to add TCP/IP since Wollongong did it for AT&T. It's an optional AT&T software product; I don't know the ordering info. I don't know what you mean by "Ethernet". It would surprise me if there weren't some Ethernet interface board for the 3B2. Whoever sells the board should be able to supply a device driver. What you do with your Ethernet connection is the interesting question.
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...)
pjh@mccc.UUCP (Peter J. Holsberg) (03/26/88)
In article <7548@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: |What you do with your Ethernet connection is the interesting question. ???? Pardon my ignorance, but I thought that there were lots of nationwide Ethernet systems that I might hook up to. Is that not so? -- Peter Holsberg UUCP: {rutgers!}princeton!mccc!pjh Technology Division CompuServe: 70240,334 Mercer College GEnie: PJHOLSBERG Trenton, NJ 08690 Voice: 1-609-586-4800
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)
In article <7556@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <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. (Or with VMS or other 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. To give proper credit, it's more than being first or easy to license, although Sun did a good job on those. I actually believe that much of the success of NFS is due directly to Sun's excellent support, as manifested in the yearly Connect-a-thon, which, in my opinion: a) Is logistically well-organized by Sun. b) Gives vendors a chance to test against more machines than any but the biggest companies could possibly own. c) Is one of the best instances of effective, efficient cooperation amongst otherwise competing vendors that I've seen. -- -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 94086
les@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).
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/27/88)
In article <1937@winchester.mips.COM> mash@winchester.UUCP (John Mashey) writes: >in the yearly Connect-a-thon, which, in my opinion: Thanks for pointing this out. > c) Is one of the best instances of effective, efficient cooperation > amongst otherwise competing vendors that I've seen. Another object lesson, perhaps?
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
hwe@beta.UUCP (Skip Egdorf) (03/28/88)
Please note that comp.arch has been removed from the Newsgroups line. This is no longer a computer architecture issue. PLEASE be good net.people and acquire the practice of at least looking at who will receive your followup. In article <4188@chinet.UUCP>, les@chinet.UUCP (Leslie Mikesell) writes: > 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. Recently, some users of a large AI application on a Symbolics 3600 felt the need to produce some pictures with Microsoft Chart. The Symbolics, for good reason, is a standalone machine that is not allowed to participate in our general network. The users spent a day trying to figure out how to get the data from the Symbolics to the PC. Suggestions were made regarding serial lines, translating Kermit to Lisp, and other worthwhile ideas. I plugged a 3-com card into the PC, strung a local ethernet to connect the two machines, loaded Sun's PC-NFS onto the the PC and ILA's EXCELLENT Symbolics implementation onto the 3600, and had the machines talking. The Symbolics performed as the NFS server and the PC mounted lispm:> as D: The users then produced their charts using the seemingly local MS-DOS files. Nary a Sun in sight!! ALL THE WORLD'S NOT UNIX. I was particularly struck at the Atlanta Usenix a few years back that the Remote File System issue was really getting shaken out. Everybody was giving papers on their remote files systems. Stateful vs Stateless was suddenly a hot topic. AT&T was the ONLY vendor pushing "Pure Unix Semantics." I was puzzled when no one else seemed to realise that this is because AT&T was now a REAL COMPUTER COMPANY whose only goal in life is to lock you into AT&T's product. (Ok, so they're not very good at it!) Naturally RFS preserves full Unix semantics. Why would AT&T want to encourage you to use all those VMS Vaxen, Lisp Machines, PCs, when they can lock you in with FULL UNIX SEMANTICS? I will never again be tied to a single vendor. I saw too many of my DECsystem-10 friends left twisting in the wind by DEC to let that happen. I really like Unix. I really like my Sun. However, Note that the Symbolics NFS is an independent implementation based on the NFS specs placed in the public domain by Sun. NFS is the closest thing that I can find to a vendor independent yet available remote file system. RFS doesn't come close on either count. NFS needs some things to be really vendor independent (e.g. support for version numbers on VMS and Lisp Machines would be nice) However, they can be added to the protocol. RFS cannot ever support such things. Skip Egdorf hwe@lanl.gov Usually I don't include disclaimers, but this time: Dear AT&T lawyers: These are my opinions, Not Los Alamos National Laboratory's. Note that this is written on a Sunday Night from a terminal at my home. Please don't take away all the Lab's nice Unix licenses. Thank you. Have a nice day.
ekrell@hector.UUCP (Eduardo Krell) (03/28/88)
In article <17056@beta.UUCP> hwe@beta.UUCP (Skip Egdorf) writes: >Naturally RFS preserves full Unix semantics. Why would AT&T >want to encourage you to use all those VMS Vaxen, Lisp Machines, >PCs, when they can lock you in with FULL UNIX SEMANTICS? You're completely missing the point. When I have a network of Suns, Vaxen and other boxes running UNIX, I DEFINITELY WANT UNIX file system semantics on remote files. I don't want my programs to be aware of the fact that the file they're operating on is remote. This is what is meant by UNIX file system semantics: the behavior is the same whether the file is local or not. It's called transparency. And AT&T is not trying to lock you into AT&T products by pushing RFS; there are a lot of non AT&T boxes running System V Release 3 and RFS. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {ihnp4,ucbvax}!ulysses!ekrell ARPA: ekrell@ulysses.att.com
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
lm@arizona.edu (Larry McVoy) (03/29/88)
In article <10186@ulysses.homer.nj.att.com> ekrell@hector (Eduardo Krell) writes: >And AT&T is not trying to lock you into AT&T products by pushing RFS; >there are a lot of non AT&T boxes running System V Release 3 and RFS. Truth in advertising, please. How about a list of those boxes? Maybe people will see the light and start to take RFS seriously? -- Larry McVoy lm@arizona.edu or ...!{uwvax,sun}!arizona.edu!lm
ekrell@hector.UUCP (Eduardo Krell) (03/29/88)
In article <4566@megaron.arizona.edu> lm@megaron.arizona.edu (Larry McVoy) writes: > >Truth in advertising, please. How about a list of those boxes? Maybe >people will see the light and start to take RFS seriously? These are the ones I've personally played with: Counterpoint Motorola NSC Bell Technologies I'm sure there are more. There was an RFS demo among at least these vendors plus AT&T at the summer Uniforum in Phoenix last year. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {ihnp4,ucbvax}!ulysses!ekrell ARPA: ekrell@ulysses.att.com
rjnoe@uniq.UUCP (Roger J. Noe) (03/29/88)
In article <4566@megaron.arizona.edu>, lm@arizona.edu (Larry McVoy) writes: > In article <10186@ulysses.homer.nj.att.com> ekrell@hector (Eduardo Krell) writes: > >there are a lot of non AT&T boxes running System V Release 3 and RFS. > > Truth in advertising, please. How about a list of those boxes? Uniq Digital Technologies ported AT&T UNIX System V Release 3 (including RFS) to DEC's VAX line (supermini to micro). Address inquiries to: Sales Department Uniq Digital Technologies, Inc. 28 S. Water St. Batavia, IL 60510 or call the switchboard on (312) 879-1566 and ask for a sales representative. I think you can also call toll-free (1-800-DEC-UNIX) but I'm not entirely certain of that; I'm not in sales. Tell them you saw it here. The transport provider for our RFS is TCP/IP derived from the original BBN code and ported to utilize STREAMS. UNIX is a registered trademark of AT&T. DEC and VAX are trademarks of Digital Equipment Corp. -- Roger Noe ihnp4!att-ih!uniq!rjnoe Uniq Digital Technologies +1 312 879 1566 Batavia, Illinois 60510 41:50:56 N. 88:18:35 W.
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>
mike@cimcor.UUCP (Michael Grenier) (04/02/88)
From article <4566@megaron.arizona.edu>, by lm@arizona.edu (Larry McVoy): > In article <10186@ulysses.homer.nj.att.com> ekrell@hector (Eduardo Krell) writes: >>And AT&T is not trying to lock you into AT&T products by pushing RFS; >>there are a lot of non AT&T boxes running System V Release 3 and RFS. > > Truth in advertising, please. How about a list of those boxes? Maybe > people will see the light and start to take RFS seriously? OK, how about any 80386 box running a port of Interactive's Unix which includes Interactive, Microport, Bell Technologies, etc. This includes all of those 386 AT clones as well as many Unix workstations such as the Convergent Server PC (which at 10000 Dhrystones isn't bad). I've seen support of RFS on the 386 AT clones using the Micom EtherNet boards and Microport claims to be supporting the Execelan 205T board as well in the near future. Michael Grenier {rutgers, amdahl, ihnp4}!bungia!cimcor!mike
stpeters@dawn.steinmetz (Dick St.Peters) (04/03/88)
In article <10186@ulysses.homer.nj.att.com> ekrell@hector (Eduardo Krell) writes: >You're completely missing the point. When I have a network of Suns, >Vaxen and other boxes running UNIX, I DEFINITELY WANT UNIX file >system semantics on remote files. I don't want my programs to >be aware of the fact that the file they're operating on is remote. >This is what is meant by UNIX file system semantics: the behavior >is the same whether the file is local or not. It's called transparency. It seems to me that "UNIX file system semantics" is not well-defined in a network environment, particularly if transparency is the goal. Consider RTI's Freedomnet, which RTI advertises as supporting full UNIX file system semantics. However, if program foo physically resides on a remote machine, typing foo causes foo to run on the remote machine. That's not what one would normally expect, but it happens to be very convenient when foo is, say, a VAX binary executeable resident on a VAX and you happen to give the command on a Sun. For most programs, this is about as transparent as you can get: from a computation (data in --> data out) point of view, you get the same result whether the file is local or not, thus meeting ekrell's criterion. However, if instead of foo, the program is reboot ... well, you get the idea. That's a pretty pathological example, but if you're running on a Cray and happen to type a command resident on a PC, you might feel that the extreme transparency of Freedomnet isn't what you want. Even under RFS, exec'ing a VAX executeable on a Sun doesn't work very well, so it can matter whether the file is local or remote. RFS thus does not support full UNIX file system semantics according to the definition ekrell gave. It appears that "transparent" and "behaving the same whether remote or local" are not equivalent, and further, neither is adequate as a criterion for the meaning of "supports UNIX file system semantics". I have my doubts whether there is any adequate definition of UNIX file system semantics for a heterogeneous distributed environment. -- Dick St.Peters GE Corporate R&D, Schenectady, NY stpeters@ge-crd.arpa uunet!steinmetz!stpeters
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 -
ekrell@hector.UUCP (Eduardo Krell) (04/03/88)
In article <10219@steinmetz.steinmetz.ge.com> dawn!stpeters@steinmetz.UUCP (Dick St.Peters) writes: >Consider RTI's Freedomnet, which RTI advertises as supporting full >UNIX file system semantics. However, if program foo physically >resides on a remote machine, typing foo causes foo to run on the >remote machine. If you consider executing a file as part of the UNIX file system semantics (which I don't), then the above behavior is not transparent. >That's not what one would normally expect, but it happens to be very >convenient when foo is, say, a VAX binary executeable resident on a >VAX and you happen to give the command on a Sun. For most programs, >this is about as transparent as you can get: from a computation (data >in --> data out) point of view, you get the same result whether the >file is local or not, thus meeting ekrell's criterion. Again, you're considering execution semantics, which clearly don't belong in the File System. On Locus (now part of IBM's AIX), you could exec any binary on any node and it would be executed on an appropriate cpu. eg, exec'ing a Vax binary from a Sun would make it run on a Vax CPU if available, fail otherwise. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {ihnp4,ucbvax}!ulysses!ekrell ARPA: ekrell@ulysses.att.com
dyer@spdcc.COM (Steve Dyer) (04/04/88)
In article <10206@ulysses.homer.nj.att.com>, ekrell@hector.UUCP (Eduardo Krell) writes: > Again, you're considering execution semantics, which clearly don't > belong in the File System. On Locus (now part of IBM's AIX), you could > exec any binary on any node and it would be executed on an appropriate > cpu. eg, exec'ing a Vax binary from a Sun would make it run on a Vax > CPU if available, fail otherwise. I was not aware that AIX incorporated any such semantics from the Locus project; it wasn't mentioned as part of IBM's AIX family definition or of their "DS"--Distributed Services, in a briefing I attended in Austin last week. "Locus" the company bears little resemblance to the UCLA project; it shares the name and a few principals. -- Steve Dyer dyer@harvard.harvard.edu dyer@spdcc.COM aka {ihnp4,harvard,husc6,linus,ima,bbn,m2c}!spdcc!dyer
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
ekrell@hector.UUCP (Eduardo Krell) (04/04/88)
In article <771@spdcc.COM> dyer@spdcc.COM (Steve Dyer) writes: >I was not aware that AIX incorporated any such semantics from the Locus >project; it wasn't mentioned as part of IBM's AIX family definition or of >their "DS"--Distributed Services, in a briefing I attended in Austin last week. I think they're calling it TCF (Transparent Computing Facility). Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {ihnp4,ucbvax}!ulysses!ekrell ARPA: ekrell@ulysses.att.com
trt@rti.UUCP (Thomas Truscott) (04/05/88)
Freedomnet, and other systems such as Sprite, support "true" remote execution in addition to the "copy/exec" execution found in NFS and RFS. One potential benefit is improved transparency of binary files. There are some interesting problems in the way. I believe Freedomnet tries harder than most to solve them. > Consider RTI's Freedomnet, which RTI advertises as supporting full > UNIX file system semantics. However, if program foo physically > resides on a remote machine, typing foo causes foo to run on the > remote machine. Freedomnet will attempt to run foo on a machine capable of executing it. If <remote machine> can execute foo, great. Otherwise Freedomnet will copy/exec it elsewhere. There are no guarantees about where the program will run (it might well migrate from one system to another during execution), however it *is* guaranteed that foo's behavior remain unchanged. There are some unobvious, yet inevitable, consequences of this guarantee. > However, if instead of foo, the program is reboot ... well, you get > the idea. [Just making sure everybody does get the idea:] Every process has a "current working system", usually referred to as the "current working root" since it is where filenames beginning with "/" are evaluated. If you run reboot then your current working system is rebooted REGARDLESS of where reboot happens to be running. Freedomnet even takes care of details such as System V's lack of a reboot system call (it has sys3b and/or uadmin), the unusual implementation of reboot() on the IBM RT, and so on. > I have my doubts whether there is any adequate definition of UNIX file > system semantics for a heterogeneous distributed environment. Your doubts are justified, given the unbounded number of ways that heterogeneity can rear its ugly head. But we should explore the limits of heterogeneous semantics, and not simply give up the fight. It is certainly no excuse for us to create systems which lack UNIX semantics even in a purely homogeneous UNIX environment! Tom Truscott P.S. There is a long section on UNIX semantics and Freedomnet in the "FREEDOMNET Programming Guide". No one seems to read it ("hey, its transparent, right?") but if you want a copy send me Email.
dwm@ihlpf.ATT.COM (Meeks) (04/06/88)
In article <4566@megaron.arizona.edu>, lm@arizona.edu (Larry McVoy) writes: > In article <10186@ulysses.homer.nj.att.com> ekrell@hector (Eduardo Krell) writes: > >And AT&T is not trying to lock you into AT&T products by pushing RFS; > >there are a lot of non AT&T boxes running System V Release 3 and RFS. > > Truth in advertising, please. How about a list of those boxes? Maybe > people will see the light and start to take RFS seriously? > -- > > Larry McVoy lm@arizona.edu or ...!{uwvax,sun}!arizona.edu!lm I know of at least one company whose workstations run SVR3 and have RFS. CounterPoint Computer Systems has a operating system they call C-XIX which is SVR3. The network of choice is RFS. The processor is 680X0. A standard system comes with 140M of hard disk and 5M of RAM. The company is real and can be found in Marchs UNIX Review not once, but twice! I seem to remember NCR's Tower system came with SVR3 and had RFS available, but I could be wrong there. CounterPoint offers: System 19, System 19K, System 22, and System 22E. --Ahead Warp Zillion--dwm ( Daniel W. Meeks @ [ihnp4!]ihlpf!iecp1!dwm )
lcc.richard@seas.ucla.edu (Richard Mathews) (04/07/88)
> In article <10206@ulysses.homer.nj.att.com>, ekrell@hector.UUCP (Eduardo Krell) writes: > > Again, you're considering execution semantics, which clearly don't > > belong in the File System. On Locus (now part of IBM's AIX), you could > > exec any binary on any node and it would be executed on an appropriate > > cpu. eg, exec'ing a Vax binary from a Sun would make it run on a Vax > > CPU if available, fail otherwise. Steve Dyer writes: > I was not aware that AIX incorporated any such semantics from the Locus > project; it wasn't mentioned as part of IBM's AIX family definition or of > their "DS"--Distributed Services, in a briefing I attended in Austin last week. > "Locus" the company bears little resemblance to the UCLA project; it shares > the name and a few principals. (For clarity, I refer to the company as LCC (Locus Computing Corp.) and the product as LOCUS) Mr. Krell is correct. The above statement by Mr. Dyer is misleading at best. While the LOCUS functionality is not part of the AIX Family Definition, it is part of AIX on the 370 and PS/2 Model 80. I suppose it's not in the Family Definition because these features have not been announced for all machines which support AIX. (I could be wrong about all of this -- someone else here says it is in the Family Definition, but I don't see it in that part of the announcement). The reason that LOCUS was not mentioned as part of DS is because DS is a totally separate product. It is my understanding is that it is NFS-like in that it provides a transparent file system capability, though with more function. I'd actually be interested in any available description of DS vs. NFS vs. anything else comparable to DS. Version 3.2 of NFS is also included in the AIX Family Definition. The AIX port for the 370 and PS/2(80) is based on work done at LCC, specifically the LOCUS Distributed Operating System first developed at UCLA. The LOCUS project is the oldest and largest of LCC's development teams. It is certainly not true that the company shares only "the name and a few principals[sic?]" with the UCLA project. Some info about an older version of the LOCUS O/S can be found in the book The LOCUS Distributed System Architecture Gerald J. Popek and Bruce J. Walker (eds.) MIT Press, 1985 The book describes some of the features of the system, as well as the protocols used to implement them (a few years ago, that is). I don't want to make this into a commercial, but in the interest of setting the record straight, here's part of the IBM announcement (number 288-130, Advanced Interactive Executive/370 (AIX/370), March 15, 1988): Transparent Computing Facility(*) (TCF) allows the distribution of data and processes among processors in a TCF cluster.... Within the TCF cluster, location of data and processes is transparent to both application programs and end users.... (*) Transparent Computing Facility is based on work done at the Locus Computing Corporation. Transparent File Systems: There is a single distributed hierarchical file system in a TCF cluster. A file may be accessed from any node in the cluster.... TCF provides a method of optionally replicating files and directories on multiple cluster nodes to increase availability and performance of the file system. The multiple copies ar kept up to date by the system.... Process Transparency: Allows a user to execute commands and run processes on any node in the TCF cluster. Work may be routed either implicitly or explicitly to the most appropriate node in the TCF cluster.... Process Migration: Allows a user to move a process in execution from one node to another of the same architecture.... The above is, of course, just my own rambling (except where I have quoted others, hopefully accurately). I am a member of the LOCUS O/S development team and coauthor of a chapter in the book, but I am not in charge of anything. With any luck, I've worded everything carefully enough that I will still have a job in the morning. AIX and lots of other things are trademarks of IBM, LCC, AT&T, and lots of other letters. Richard M. Mathews Locus Computing Corporation lcc.richard@CS.UCLA.EDU {ihnp4,ucla-cs,trwrb}!lcc!richard
dyer@spdcc.COM (Steve Dyer) (04/07/88)
I stand completely corrected. Thanks for the lowdown from someone who knows better... -- Steve Dyer dyer@harvard.harvard.edu dyer@spdcc.COM aka {ihnp4,harvard,husc6,linus,ima,bbn,m2c}!spdcc!dyer
bzs%bu-cs.bu.edu@buita.bu.edu (Barry Shein) (04/07/88)
>With any luck, I've worded everything carefully enough that I >will still have a job in the morning. Funny how IBM brings that out in people... I went to two separate presentations by two separate groups a couple of weeks ago. One was on DS and the other was on LOCUS (all w/in the AIX context.) DS is another in the series NFS...RFS...(etc)FS. It basically is a stateful remote filing system with a promise to preserve things like locking semantics. Currently it's only available on an SNA transport but there were plans (I believe approx. dates were given) to make it available on Internet protocols and ethernet and all that stuff. It wasn't at all clear that there was any intention to make it available to non-IBM vendors other than the usual "we are considering that" (or is the practiced wording "that would be a logical thing to do...".) LOCUS was available on 370 Architecture and PS/2's (model 80's? I don't remember, but '386.) It seemed one of the major uses was that you could put binaries on either system (370 or 386) compiled for either (got that?) and it would figure out which it should run on. As well as a single file-system view (I don't think this was meant to be quite NFS'ish, more like the sum of the machines is the whole.) There was some small limit (at least for a 3090/200 like ours) of PS/2's you could hook up (31?) tho the conversation turned to setting up M thingamajigs of N each and then everything went blank. One use presented was to attach ASCII terminals (or even come in over an ethernet from a workstation) to the 386's and use them as front end concentrators. The idea would be that you could run (eg) a full-screen editor on the local PC host against files on the 370 and otherwise proceed as if you were working on the 370. This seemed like a useful idea (how well it all works I have no idea, there was no demo) as IBM mainframes really hate full-duplex style interfaces, so let the PC handle it. Note that all previous releases of Unix (IBM, Amdahl, AT&T) required some sort of special equipment to accomplish full-duplicity (eg. Series/1, modified 4705 etc.) So this aspect is right in line and could be better than buying a bunch of Series/1's anyhow. Fortunately they (IBM) did include support of NFS over Internet protocols (ethernet etc.) The DS looks like an uphill battle, particularly in environments like my own where we have probably 100+ systems running NFS in an heterogeneous environment. I'm not certain the world really needs yet-another-remote-file-system, but I'm sure the market will decide. At any rate, I have no doubt there are more than a few IBM systems out there w/o any NFS and plenty of SNA and this will, I presume, look attractive to them. I dunno, raised as many questions as it answered in my mind. I suppose it will all be answered in the fullness of time... Perhaps someone from IBM can fill in the missing pieces (hah!) -Barry Shein, Boston University
jc@minya.UUCP (John Chambers) (04/07/88)
> Even under RFS, exec'ing a VAX executeable on a Sun doesn't work very > well, so it can matter whether the file is local or remote. RFS thus > does not support full UNIX file system semantics according to the > definition ekrell gave. Hey, wait a minute, exec isn't really a file-system operation, except in the trivial sense that everything is a file-system operation. (After all, /dev/mem exists, so a store operation changes a file...:-) File operations are things like open(), read(), .... > I have my doubts whether there is any adequate definition of UNIX file > system semantics for a heterogeneous distributed environment. Well, an interesting argument is that most Unix systems have file systems made up of multiple disks and/or partitions mounted together. The only thing new in a 'distributed' system is that the disks or partitions are owned by different processors. This is a rather irrelevant matter as far as the file systems are concerned. There should be no difference between one computer that owns two disks and two computers, each of which owns one disk. The Unix model works just fine in either case. As for exec problems, you can easily get them in an isolated Unix system. Just install a cross-compiler. For instance, port the VAX C compiler to your Sun, and see how well the Sun execs the output. Lots of people do things like this. The distributed case adds no extra complexity. -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)
karish@denali.UUCP (karish) (04/07/88)
In article <12852@brl-adm.ARPA> lcc.richard@seas.ucla.edu (Richard Mathews) writes: > >The reason that LOCUS was not mentioned as part of DS is because DS >is a totally separate product. It is my understanding is that it is >NFS-like in that it provides a transparent file system capability, >though with more function. I'd actually be interested in any >available description of DS vs. NFS vs. anything else comparable to DS. >Version 3.2 of NFS is also included in the AIX Family Definition. > >Richard M. Mathews >Locus Computing Corporation lcc.richard@CS.UCLA.EDU I've been using Distributed Services on PC-RTs for several months, and can share some impressions. DS is more powerful than NFS in that it allows users (anyone who has write permission for the mount point, and read permission for the file to be mounted) to mount any ordinary file or directory from a remote machine. Mounts may be inherited, meaning that if I mount a directory which itself includes a mounted remote object, I'll be able to use the files referenced by the second-order mount. User ID numbers are individually mapped from one host to another, so the system administrator can fine-tune access more easily than is possible under NFS. 'ls -l' prints a D in the first column for a remotely-mounted directory, and F for a file. The present AIX version of DS is layered on top of SNA. The IBM sales people say that the version that ties together the whole IBM world will use TCP/IP for transport. There was an article on DS in ;login last fall; ask the usenix office or an IBM salesperson for a copy, if you want more information. Chuck Karish Disclaimer: RT-PC, Distributed Services, AIX, and IBM are trade marks of the International Business Machines Corporation. While my employer produces software under contract to IBM, I have no personal financial interest in the sale of any IBM product.
jqj@uoregon.UUCP (JQ Johnson) (04/09/88)
One major advantage of Locus that has been mentioned but not, I think, given the attention it deserves is file replication. As systems become more and more complex, the work a person does starts more and more to be dependendent on the simultaneous availability of numerous files. Meanwhile, as remote file systems become larger and more complex, the number of file servers in a cluster increases and it becomes likely that the user will depend on the availability of several file servers simultaneously. On a typical NFS sun cluster I depend on the machine I'm swapping to (presumably the same machine that has my /usr.MC68020 on!), the machine that has my home directory on it, the machine that has the project files I'm editing on it, and perhaps the machine that has the experimental tools I'm using. Assuming 95% uptime for each server, then at least one will be down 1/5 of the time! Worse, there are some files that it is important to have available at all times, but that you may not want to maintain multiple copies of (e.g. /etc/passwd or /.login). SUN solves this problem using a replicated YP plus rdist, but that doesn't generalize well to frequently updated non-database files that one might want "the same" on all workstations. A solution to both problems is to make the files remote, and put them on a replicated file server. A project at Cornell last year built a simple replicated NFS server based on the Isis distributed system; contact Ken Birman or Keith Marzullo <ken@gvax.cs.cornell.edu>, <marzullo@gvax.cs.cornell.edu> for details. NFS has the advantage (over such protocols as ATT RFS) of being simple enough to make such a value-added server possible. However, this requires adding a substantial amount of state information to the NFS server, and allows much less inteligent replication than you could get if you had smart rfs clients that participated in the replication/ synchronization (implying, I think, that an rNFS must give poor performance, though Ken might disagree). Locus has the singular advantage of having been built from the ground up to allow file replication.
geoff@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/14/88)
In article <10219@steinmetz.steinmetz.ge.com>, stpeters@dawn.steinmetz (Dick St.Peters) writes: > In article <10186@ulysses.homer.nj.att.com> ekrell@hector (Eduardo Krell) writes: >> When I have a network of Suns, Vaxen and other boxes running UNIX, I >> DEFINITELY WANT UNIX file system semantics on remote files. [...] >> This is what is meant by UNIX file system semantics: the behavior is >> the same whether the file is local or not. It's called transparency. > It seems to me that "UNIX file system semantics" is not well-defined > in a network environment, particularly if transparency is the goal. > Consider RTI's Freedomnet, which RTI advertises as supporting full > UNIX file system semantics. However, if program foo physically > resides on a remote machine, typing foo causes foo to run on the > remote machine. This is `transparent' if, and only if, foo would also run on the remote machine after copying it to some local filesystem. Otherwise, well, sorry, their marketing people got ahead of themselves. > Even under RFS, exec'ing a VAX executeable on a Sun doesn't work very > well, so it can matter whether the file is local or remote. RFS thus > does not support full UNIX file system semantics according to the > definition ekrell gave. It doesn't matter whether the file is local or remote; it matters what's in it! If you copy the VAX executable to the Sun's local disk, it doesn't work any better (or worse). Thus, it *doesn't* matter whether the file is local or remote. > It appears that "transparent" and "behaving the same whether remote > or local" are not equivalent, Then someone's playing word games. That's what I always thought (and continue to think) it means. That's what I mean when I use it, and that's what I understand the speaker/writer to mean when I hear/read it. > and further, neither is adequate as a criterion for the meaning of > "supports UNIX file system semantics". Well no, behaving the same whether the file is remote or local doesn't necessarily imply UNIX filesystem semantics. UNIX filesystem semantics are the things specified in the manual: the various calls must work as they are supposed to. der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu
trt@rti.UUCP (Thomas Truscott) (04/14/88)
In article <1053@mcgill-vision.UUCP>, mouse@mcgill-vision.UUCP (der Mouse) writes: > > > Consider RTI's Freedomnet, which RTI advertises as supporting full > > UNIX file system semantics. However, if program foo physically > > resides on a remote machine, typing foo causes foo to run on the > > remote machine. > > This is `transparent' if, and only if, foo would also run on the remote > machine after copying it to some local filesystem. Yes, as I explained previously, if foo is the wrong binary type for the machine where it resides then it is copy/executed elsewhere. We implemented that ("misplaced execution") over three years ago. Once you have true remote execution this sort of thing is fairly straightforward. Tom Truscott
allbery@ncoast.UUCP (Brandon Allbery) (04/16/88)
As quoted from <465@cimcor.UUCP> by mike@cimcor.UUCP (Michael Grenier): +--------------- | From article <4566@megaron.arizona.edu>, by lm@arizona.edu (Larry McVoy): | > In article <10186@ulysses.homer.nj.att.com> ekrell@hector (Eduardo Krell) writes: | >>And AT&T is not trying to lock you into AT&T products by pushing RFS; | >>there are a lot of non AT&T boxes running System V Release 3 and RFS. | > | > Truth in advertising, please. How about a list of those boxes? Maybe | > people will see the light and start to take RFS seriously? | | OK, how about any 80386 box running a port of Interactive's Unix which | includes Interactive, Microport, Bell Technologies, etc. This includes +--------------- Also Altos System V, which leans rather closer to Xenix than to Interactive's 386 port; not to mention their Unix for the 3068 (68020 box). I also understand that Plexus (680x0 boxes) is dropping its proprietary NOS and going RFS in its V.3 port (if and when it comes out, unless you bought a P/95 which has it now). -- Brandon S. Allbery, moderator of comp.sources.misc {well!hoptoad,uunet!hnsurg3,cbosgd,sun!mandrill}!ncoast!allbery
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
allbery@ncoast.UUCP (Brandon Allbery) (04/24/88)
As quoted from <1053@mcgill-vision.UUCP> by mouse@mcgill-vision.UUCP (der Mouse): +--------------- | In article <10219@steinmetz.steinmetz.ge.com>, stpeters@dawn.steinmetz (Dick St.Peters) writes: | > UNIX file system semantics. However, if program foo physically | > resides on a remote machine, typing foo causes foo to run on the | > remote machine. | | This is `transparent' if, and only if, foo would also run on the remote | machine after copying it to some local filesystem. Otherwise, well, | | > Even under RFS, exec'ing a VAX executeable on a Sun doesn't work very | > well, so it can matter whether the file is local or remote. RFS thus | | It doesn't matter whether the file is local or remote; it matters | what's in it! If you copy the VAX executable to the Sun's local disk, +--------------- I dunno about you, but if I've got my home directory on some machine "A" mounted on machine "B" (with a different hardware processor), I do *not* consider it "transparent" if I can't run a binary in my bin directory on "A" from "B" without invoking rsh! (I encounter this using Worknet between 8086 and 80286 machines.) Perhaps what you describe is "transparent" under some definition, but to Joe End-User what you describe is a discontinuity: the file is "on both systems" but only useable on one of them. As far as the end user is concerned, the network isn't transparent, it just reached out and punched him in the nose. -- Brandon S. Allbery, moderator of comp.sources.misc {well!hoptoad,uunet!marque,cbosgd,sun!mandrill}!ncoast!allbery Delphi: ALLBERY MCI Mail: BALLBERY