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
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).
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 )
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)
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
rwhite@nusdhub.UUCP (Robert C. White Jr.) (04/26/88)
in article <7675@ncoast.UUCP>, allbery@ncoast.UUCP (Brandon Allbery) says: > 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. I will aplaud you when you write the "universal binary translator" capible of allowing _any_ binary to run on _any_ machine. RFS & NFS are [read my lips if necessary] "FILE-SYSTEM EXPORT LINKS" they are not intended to convert object/load/instruction fromats [on a binary executable level] into a format capible of running on whatever machine you happen to be living on at that moment. RFS allows you to make files available to different machines. It does this quite nicely, thankyou. It does this so nicely in fact, that you can even access special devices through the network [though you DO have to be a little careful here]. As to your moaning about a universal exchange system, I sugguest you write one and then try to market it. If it's any good, I'm shure you will make a mint. Meanwhile, put up or shut up. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< << All the STREAM is but a page,<<|>> Robert C. White Jr. << << and we are merely layers, <<|>> nusdhub!rwhite nusdhub!usenet << << port owners and port payers, <<|>>>>>>>>"The Avitar of Chaos"<<<<<<<<<<<< << each an others audit fence, <<|>> Network tech, Gamer, Anti-christ, << << approaching the sum reel. <<|>> Voter, and General bad influence. << <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ## Disclaimer: You thought I was serious???...... Really???? ## ## Interogative: So... what _is_ your point? ;-) ## ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^