RFS vs. NFS
Michael Lodman
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....@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.
John Kullmann
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
Doug Gwyn
>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.).
Larry McVoy
> 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 l...@arizona.edu or ...!{uwvax,sun}!arizona.edu!lm
Roy Smith
j...@apple.UUCP (John Kullmann) writes:
> Everyone wants and uses NFS and no one wants or uses RFS.
To which gw...@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
Bruce G. Barnett
|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 <bar...@ge-crd.ARPA> <bar...@steinmetz.UUCP>
uunet!steinmetz!barnett
Jerome Freedman
Excuse my ignorance but this is a chance to nibble away at
it. Could someone explain to me, for 4.2 especially the Sun
version exactly how and in what order the .login and .cshrc
files are read (executed?). How are these files handled when
you initiate Suntools? How are they handled if you "su" to
another account? How are they handled in an rlogin? How
about them Celtics?
Thank you
Jerry Freedman, Jr "Love is staying up all night
jf...@mitre-bedford.arpa with a sick child,
(617)271-4563 or a healthy adult"
Rob Logan
> j...@apple.UUCP (John Kullmann) writes:
>> Everyone wants and uses NFS and no one wants or uses RFS.
>
> To which gw...@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
Zdenko Tomasic
>From article <32...@phri.UUCP>, by r...@phri.UUCP (Roy Smith):
>> j...@apple.UUCP (John Kullmann) writes:
>>> Everyone wants and uses NFS and no one wants or uses RFS.
>>
>> To which gw...@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
>
>r...@sun.soe.clarkson.edu
Zdenko Tomasic
UWM, Chem. Dept.
Milwaukee,WI,53201
__________________________________________________________
UUCP: ihnp4!uwmcsd1!csd4.milw.wisc.edu!zdenko
ARPA: zde...@csd4.milw.wisc.edu
__________________________________________________________
Doug Gwyn
>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.
Doug Gwyn
>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.
Rick Sample
>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
Barry Shein
From Doug Gwyn
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
Barry Shein
>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.
Doug Alan
> 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
Larry McVoy
>In article <75...@brl-smoke.ARPA> gw...@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.
Doug Gwyn
>|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...
Peter J. Holsberg
|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
William E. Davidsen Jr
| 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 (we...@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me
karish
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
John Kullmann
>>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!
Robert Plamondon
>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"
John Kullmann
>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.
Doug Gwyn
>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.
Franklin Reynolds
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
f...@ksr.uucp
ksr!f...@harvard.harvard.edu
harvard!ksr!fdr
Kendall Square Research Corporation
Building 300 / Hampshire Street
One Kendall Square
Cambridge, Ma 02139
Roy Smith
> >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)
Larry McVoy
>In article <44...@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.
Dave Curry
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
John F Carr
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
j...@athena.mit.edu On the price of being free" -- Neil Peart
alan denney
the post attempt...
You may have been "RTFM"d for this, but I have seen a lot of people get
confused about this, so don't feel too bad. (Public note: the man
pages for "su" and "csh" appear to disagree).
The .cshrc file is read and executed (if possible) upon every csh
fireup, INCLUDING the login shell. The .login is read and executed
AFTER the .cshrc. If either file is not owned by the person logging
in, it is not executed. (Of course, root can use /usr/5bin/chown to
change ownership for a new user.)
Of course, things get confusing if the user does something silly,
like having a "source .login" command within the .cshrc (which I
have seen more than a few times ;-]).
> How are these files handled when you initiate Suntools?
Sorry, over my lowly head..
> How are they handled if you "su" to another account?
When using "su": if the default shell for the user su'd to is csh,
that user's .cshrc is executed. If "su - usernm" is used, the .login
is also executed (again, AFTER the .cshrc). The man page for "su"
states (quoted without permission, please forgive me, Sun):
| SYNOPSIS
| su [ - ] [ username ] [ -c command ] [ -f ]
|
| OPTIONS
| - The - flag performs a complete login. That is, it
| moves to the home directory, reads the .login file, and
| reads the .cshrc file for the new user-ID to configure
| the new shell.
|
| Sun Release 3.4 Last change: 17 February 1986 1
This is a good source of confusion; the .cshrc is executed FIRST.
I would interpret this passage to claim that the .login goes first.
(Any Sun documentation people out there?)
> How are they handled in an rlogin?
Just the same as a direct login. I believe that "rsh" invokes the
.cshrc file (only) of the user on the remote machine.
> How about them Celtics?
How about them Giants!
--
Alan S. Denney | {pyramid|uunet}!infmx!aland
Informix Software, Inc. | CAUTION: This terminal makes wide right turns!
Disclaimer: These opinions are mine alone. If I am caught or killed,
the secretary will disavow any knowledge of my actions.
Randell E. Jesup
now to comp.arch, if it ever did (also some other discussions about
magtape are being x-posted). Please edit the newsgroups line when you
respond to these. Please.
// Randell Jesup Lunge Software Development
// Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180
\\// beowulf!lunge!je...@steinmetz.UUCP (518) 272-2942
\/ (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesup
(-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)
Barry Shein
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
Doug Gwyn
>gw...@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
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!)
Doug Gwyn
>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...)
Peter J. Holsberg
???? Pardon my ignorance, but I thought that there were lots of nationwide
Ethernet systems that I might hook up to. Is that not so?
karish
>In article <27...@linus.UUCP>, jf...@mitre-bedford.ARPA (Jerome Freedman) writes:
>> Excuse my ignorance but this is a chance to nibble away at
>> it. Could someone explain to me, for 4.2 especially the Sun
>> version exactly how and in what order the .login and .cshrc
>> files are read (executed?). How are these files handled when
>> you initiate Suntools? How are they handled if you "su" to
>> another account?
>
>fireup, INCLUDING the login shell. The .login is read and executed
>AFTER the .cshrc. If either file is not owned by the person logging
>in, it is not executed. (Of course, root can use /usr/5bin/chown to
>change ownership for a new user.)
>
>
>When using "su": if the default shell for the user su'd to is csh,
>that user's .cshrc is executed.
Csh behaves differently on some SysV systems. AIX doesn't source
.cshrc on an su. This causes me no end of annoyance and confusion
when I maintain workstations whose users insist on making root's
default shell csh (yes, I know how to fix this with an alias).
AIX also will refuse a login if the user does not own his/her
.cshrc, .login, or .profile.
Chuck
Robert Viduya
> ... 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 rob...@pyr.gatech.edu
Office of Computing Services
Georgia Institute of Technology (404) 894-6296
Atlanta, Georgia 30332-0275
Eduardo Krell
>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: ekr...@ulysses.att.com
Juergen Wagner
>You may have been "RTFM"d for this, but I have seen a lot of people get
Actually, if you don't have some experience with UNIX it is a case of
RTMVC (Read The Manual Very Carefully) :-) :-).
>... (Public note: the man
>pages for "su" and "csh" appear to disagree).
The csh(1) man page says that .cshrc is executed first, then .login if the
newly created shell is a login shell. The su(1) man page is inconsistent.
The login(1) manpage is correct. The rlogin man page doesn't mention anything
about that matter at all.
>...
>Of course, things get confusing if the user does something silly,
>like having a "source .login" command within the .cshrc (which I
>have seen more than a few times ;-]).
Source'ing .login in .cshrc should not do anything bad if .login is written
properly (e.g. make uses of stty/biff/etc. conditional on interactiveness).
Yet, it doesn't make any sense, either :-).
>> How are these files handled when you initiate Suntools?
When you startup Suntools, this is typically handled in the .login. The
point is that .cshrc is executed every time a csh starts (e.g. when FranzLISP
starts its assembler). Put in this file everything you'd like to have in
every csh. Put into .login everything you need in the login shell, and
all environment variables not needed in all cshs. Also, terminal setup
(tset, stty, biff, ...) should be in .login because in .cshrc it doesn't
make sense. So, typically .login runs Suntools. Each cmdtool/vt100tool/
shelltool starts a new csh, i.e. executes .cshrc but *BUT* no .login.
>> How are they handled in an rlogin?
Exactly same as normal login. The csh starts and reads .cshrc, notices
that it is a login shell, and reads .login. All this happens, of course,
on the remote machine. rsh (BSD) and remsh (HPUX) invoke only .cshrc.
>> How about them Celtics?
Sounds interesting. What does it mean?
--
Juergen Wagner, gan...@csli.stanford.edu
Center for the Study of Language and Information (CSLI), Stanford CA
Juergen Wagner
>...
>Csh behaves differently on some SysV systems. AIX doesn't source
>.cshrc on an su.
Yes, HPUX doesn't read cshrc, either. Or, I should say - it reads your
.cshrc, and doesn't care about the new user's .cshrc. It even takes
HOME and the other environment variables just from the parent process,
so simple "cd" brings you back into *YOUR* home directory, not into
the directory of the user to su'ed to.
"su - user" does read .cshrc *AND* .login under HPUX.
--Juergen
Leslie Mikesell
>that one of the explicit design goals of NFS was to work not
>only with UNIX filesystems but also with MS-DOS filesystems.
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
Doug Gwyn
>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).
Dick St.Peters
[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
stpe...@ge-crd.arpa
uunet!steinmetz!stpeters
--
Dick St.Peters
GE Corporate R&D, Schenectady, NY
stpe...@ge-crd.arpa
uunet!steinmetz!stpeters
Jacob Gore
>The point is that .cshrc is executed every time a csh starts ([...]).
>Put in this file everything you'd like to have in every csh. Put into
>.login everything you need in the login shell, and all environment variables
>not needed in all cshs. Also, terminal setup (tset, stty, biff, ...) should
>be in .login because in .cshrc it doesn't make sense.
I find that this sequence (.cshrc first, then .login) is the opposite of what
I want. That is because I want to set up environment variables just once --
in .login, -- and I want them to be usable from .cshrc in each shell I use,
including the login shell.
So, I just reverse them:
.login (abbridged):
setenv EDITOR /usr/local/bin/mg
unset autologout
set prompt="%m"; setenv SHOSTNAME $prompt
biff y
setenv HAVELOGGEDIN yes
source ~/.tcshrc
.tcshrc (abbridged):
if (${?HAVELOGGEDIN}) then
source ~/.customrc
set prompt="`whoami`@${SHOSTNAME}> "
set history=50 savehist=20
endif
This way, when the login shell starts up, .tcshrc skips itself (because
HAVELOGGEDIN is not defined), .login is run, and it runs .tcshrc when it's
finished.
On subsequent shells, just the .tcshrc is run, and it executes normally.
Jacob Gore Go...@EECS.NWU.Edu
Northwestern Univ., EECS Dept. {oddjob,gargoyle,ihnp4}!nucsrl!gore
Skip Egdorf
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 <41...@chinet.UUCP>, l...@chinet.UUCP (Leslie Mikesell) writes:
> In article <75...@brl-smoke.ARPA> gw...@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
h...@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.
Eduardo Krell
>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.
George W. Leach
>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
Larry McVoy
>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?
Mike Clarkson
| In article <2...@denali.UUCP| crka...@stanford.edu (Chuck Karish) writes:
| >Csh behaves differently on some SysV systems. AIX doesn't source
| >.cshrc on an su.
|
| Yes, HPUX doesn't read cshrc, either. Or, I should say - it reads your
| .cshrc, and doesn't care about the new user's .cshrc. It even takes
| HOME and the other environment variables just from the parent process,
| so simple "cd" brings you back into *YOUR* home directory, not into
| the directory of the user to su'ed to.
Same with most SysV's. But and interesting bsd feature (?) is that it
will only source the .login if the user logging in owns that file. For
example, if I'm logging in as mike, and ~mike/.login is owned by root,
the ~mike/.login will not be executed.
--
Mike Clarkson mi...@ists.UUCP
Institute for Space and Terrestrial Science
York University, North York, Ontario,
CANADA M3J 1P3 (416) 736-5611
Eduardo Krell
>
>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.
Roger J. Noe
> In article <10...@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.
Joe Pruett
quite obnoxious when you set your path in your .login (where it belongs
so that each shell isn't hashing your path more than necessary).
"rsh hostname something_in_usr_local_bin" will get you a "Command not
found" message. To get around this problem I've renamed .login to
.mylogin and created a new environ variable that let's my .cshrc know
if my .mylogin has been run, if not then .cshrc sources .mylogin.
In .cshrc:
if ( ! ${?MYLOGIN} ) source ~/.mylogin
.
.
In .mylogin:
set path = ( . . . )
.
.
setenv MYLOGIN ""
This could be cleaned up a little bit (move the env stuff into
.cshrc inside the if MYLOGIN line), but inertia can be quite
overwhelming.
--
Joe Pruett ...!tektronix!tessi!joey
Tim Beres
>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 be...@cadnetix.com
<disclaimers: my thoughts != Cadnetix's>
G. Roderick Singleton
>In article <44...@megaron.arizona.edu> l...@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
Eduardo Krell
"The - option simulates a full login" (in 4.3 BSD).
The System V man page is less cryptic:
If the first argument to su
is a -, the environment will be changed to what would be
expected if the user actually logged in as the specified
user. This is done by invoking the program used as the
shell with an arg0 value whose first character is -, thus
causing first the system's profile (/etc/profile) and then
the specified user's profile (.profile in the new HOME
directory) to be executed. Otherwise, the environment is
passed along with the possible exception of $PATH, which is
set to /bin:/etc:/usr/bin for root.
Kurt Zeilenga
>As has been mentioned, rsh does not source your .login file. This is
>quite obnoxious when you set your path in your .login (where it belongs
It would really obnoxious if it did source your .login.
>so that each shell isn't hashing your path more than necessary).
What? I assume you don't want it to be "hasing your path more than
necessary" for speed. You need to set your path once per shell to
make sure it's right. You don't want to rely on it being correct
in the environment.
>"rsh hostname something_in_usr_local_bin" will get you a "Command not
>found" message. To get around this problem I've renamed .login to
>.mylogin and created a new environ variable that let's my .cshrc know
>if my .mylogin has been run, if not then .cshrc sources .mylogin.
>
>In .cshrc:
>if ( ! ${?MYLOGIN} ) source ~/.mylogin
So you source a script. Now, that makes a lot of sense and I am sure
would be much faster than just setting your path .cshrc. If I am doing
a rsh, I won't want it to check for mail, news, etc, tset my terminal,
etc. Yuk!
>This could be cleaned up a little bit (move the env stuff into
>.cshrc inside the if MYLOGIN line), but inertia can be quite
>overwhelming.
>--
>Joe Pruett ...!tektronix!tessi!joey
Why don't you put things you want done once per shell in .cshrc
and things you want done once per login in .login. If you have
stuff that you don't want done when you are doing rsh's (for
speed or other reasons) then do a "if ($?prompt) then" or
something in your .cshrc. If you want to put something into
your .cshrc to do something once per .login, because of some
order dependence which you might have, just check for the
non-existance of an environment variable you set in your .login
(like your MYLOGIN).
--
Kurt (zeil...@hc.dspo.gov)
Michael Grenier
> In article <10...@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
Dick St.Peters
>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.
Robert Bownes
> In article <2...@ksr.UUCP> f...@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
bown...@beowulf.uucp (518)-482-8798 | must be true.
{steinmetz,brspyr1,sun!sunbow}!beowulf!bownesrm | - me, tonite -
Eduardo Krell
>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.
Steve Dyer
> 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
dy...@harvard.harvard.edu
dy...@spdcc.COM aka {ihnp4,harvard,husc6,linus,ima,bbn,m2c}!spdcc!dyer
Barry Margolin
> 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);
C...@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.
bar...@think.com
uunet!think!barmar
Eduardo Krell
>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).
Thomas Truscott
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.
Meeks
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 )
Jerry Aguirre
>quite obnoxious when you set your path in your .login (where it belongs
>so that each shell isn't hashing your path more than necessary).
I disagree. My path is set in my .cshrc. The setting is conditional on
and environment variable so that sub shells don't reset it. It looks
like:
if (! $?MAIL) then
setenv MAIL /usr/spool/mail/jerry
set path=(. ~jerry/bin /usr/ucb /bin /usr/bin)
endif
This is a lot simpler than inventing new files to be sourced. I bet it
is faster too. (I don't remember what program wanted a "MAIL" variable,
any environment variable not set at login time would do.)
People should also be aware that setting the prompt in their .cshrc
should also be conditional. They should use something like:
if ($?prompt) then
set histchars=\\^
set prompt="\> " history=60 mail=(120 /usr/spool/mail/$USER)
alias 1 %1
...
endif
Anything dealing with prompts, history, or any other "interactive"
variable should be executed only for interactive logins. My opinion is
that almost all aliases should also be conditional. An alias is used
primarily to save typing and that doesn't apply to non-interactive
usage.
John Chambers
> 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)
R.H. coast near the top
> 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:gar...@sun.com | on. G.A.]
der Mouse
> In article <10...@ulysses.homer.nj.att.com> ekrell@hector (Eduardo Krell) writes:
>> When I have a network of Suns, Vaxen and other boxes running UNIX, I
>> 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: mo...@mcgill-vision.uucp
arpa: mo...@larry.mcrcim.mcgill.edu
Thomas Truscott
>
> > 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
Brandon Allbery
+---------------
| From article <45...@megaron.arizona.edu>, by l...@arizona.edu (Larry McVoy):
| > In article <10...@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
der Mouse
> In article <6...@leah.Albany.Edu> rmb...@leah.Albany.Edu (Robert Bownes) writes:
>> NFS was designed to be OS independant.
> 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.)
Brandon Allbery
+---------------
| In article <10...@steinmetz.steinmetz.ge.com>, stpe...@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,
|
| > well, so it can matter whether the file is local or remote. RFS thus
|
| 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
Robert C. White Jr.
> 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? ;-) ##
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^