vanni@mit-bug.UUCP (Giovanni Aliberti) (12/16/85)
Has any one done any work on a UNIX extended file system ?? The minimal `feature' of such a file system, would be to allow individual file access, via pathnames. For example; from machine A, one would cat a file on machine B with: cat A:/usr/jon/.login or cat /dev/net/A/usr/jon/.login A bit similar to `rcp', except that open(), close(), read(), write() ... will be implemented as a `DEVICE' at the kernel level. Any ideas, suggestion ?? Giovanni
chuq@sun.uucp (Chuq Von Rospach) (12/17/85)
> Has any one done any work on a UNIX extended file system ?? > The minimal `feature' of such a file system, would > be to allow individual file access, via pathnames. > > For example; from machine A, one would cat a file on machine B > with: > cat A:/usr/jon/.login > or > cat /dev/net/A/usr/jon/.login The purdue people put together something called ibis that moved the <host>:<file> down to the library level. It was slow and relatively flakey, but I think someone was looking at moving it into the kernel. On more transparent access issues, you can look at the Newcastle connection (V7 based) which uses a superroot scheme or NFS, which was developed by Sun and is spreading out into the rest of the world. NFS is transparent -- you mount remote directories onto the local system with the 'mount' call and from then on you don't care where it comes from. Since I work on NFS at sun I don't want to turn this into a commercial -- if you're interested in learning more, drop me a line. chuq -- :From catacombs of Castle Tarot: Chuq Von Rospach sun!chuq@decwrl.DEC.COM {hplabs,ihnp4,nsc,pyramid}!sun!chuq Power ennobles. Absolute power ennobles absolutely.
dpk@mcvax.UUCP (Doug Kingston) (12/18/85)
The answer is that there is ongoing work on a remote file system
for 4.3BSD. I am currently about to Alpha test a remote filesystem
whose development started at BRL with help from Dan Tso at Rockafeller
University, and has been continued here at CWI (mcvax). The system
uses a kernel mode client and a user mode server.
The RFS is completely transparent to the client system. No user mode
changes are required except to replace the mount/umount programs and
recompile the kmem readers (due to changes in some data structures).
It supports remote chdir, remote core dumps, and all other 4.{2,3}
filesystem related system calls. Remote file systems are currently
mounted just as regular filesystems are mounted. This mechanism may
be augmented to happen automatically later. Authentication is currently
done via the hosts.equiv/.rhost mechanism. Other security measures can
be easily implemented in the user mode server.
Current performance 750/file to 750/dev/null is about 30 Kbytes per second.
This should improve but will never exceed that of RCP and should be slightly
less due to the added overhead of true RPC over the TCP connection.
Now the good news: The CWI/BRL RFS will be made available on mod.sources
when it has sufficently stable. I expect this to be just after
4.3BSD is released, but not before the end of January. I will be sending
diffs of the altered files and the new files I wrote. The RPC protocol has
been designed to map very closely to the 4.2BSD system calls and has
provisions for negotiating byte order, directory format and other machine
and OS dependent actions. It currently uses TCP but is quite able to
exist on other reliable transport systems, either STREAM or DGRAM.
RDP would be a prime choice.
It should port easily to 4.2BSD and 4.2BSD derived systems.
When the system is about to be come available, a note will be sent to
this newsgroup (amongst others). If you have specific inquiries about
this, please address them to me personally: dpk@mcvax.uucp.
Cheers and Merry Christmas!
-Doug-gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (12/19/85)
> ... NFS is transparent ...
Well, not quite. Some of the UNIX file systems semantics
are not honored by NFS, which was designed to accommodate
MS/DOS as well as UNIX.roy@phri.UUCP (Roy Smith) (12/19/85)
> Some of the UNIX file systems semantics > are not honored by NFS, which was designed to accommodate > MS/DOS as well as UNIX. Interesting. Can somebody provide more details on this? -- Roy Smith <allegra!phri!roy> System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
ron@isieng.UUCP (Ronald P. Hughes) (12/20/85)
In response to your inquiry regarding extended file systems under 4.2/4.3: Here at Integrated Solutions I have implemented TRFS (Transparent Remote File System) which allows access to remote files. It is implemented within the kernel, so that existing programs can make use of it without recompilation or relinking. Anywhere you can specify a filename or pathname, you can now specify a remote pathname of the form "/@machinename/pathname", where pathname is any arbitrary pathname on the remote machine. For instance, you can "cat /@bert/etc/passwd" to look at a remote file, or do something like "vi /@bert/usr/demo/hello.c" to examine (and/or modify) a particular file. If you want to browse, you can always "cd /@bert/usr/demo; ls -l; vi *.c". If you don't like the remote pathname syntax, try "ln -s /@bert /B". Since the target of a symbolic link can be a remote pathname, remote filesystem mounting is not needed. In fact, there are NO new system calls associated with TRFS. All the standard protection mechanisms apply. Remote files can be locked, and remote devices can be accessed. One of our customers discovered that after "ln -s /@bigmachine/dev/rmt0 /dev/rmt0" he could invoke tar in the conventional manner to extract files from a remote tape drive. My apologies to those who are offended by any kind of hype on the network. Further inquiries should be directed to me at pyramid!isieng!ron, and flames should be directed to /@bert/dev/null. Ronald P. Hughes Integrated Solutions pyramid!isieng!ron (408)943-1902
bzs%bostonu.csnet@csnet-relay.arpa (Barry Shein) (12/20/85)
Chuq hesitated to overview the SUN NFS for fear of being accused of commercialism. I for one would love to hear an overview of the system tailored for the level of this group, from someone who knows, and that's likely to be someone within SUN. Given the fact that SUN has bent over backwards to get other vendors to adopt the protocol (making specs and code available) it borders on silly to feel that this is very commercial (it would be like discouraging AT&T folks from talking about UNIX.) [Oh, and many vendors seem to be real serious about implementing it very soon.] There was an article overviewing it (and contrasting it to Apollo/Domain and, especially, ATT/RFS) in this past UNIX/WORLD 'zine, but as is typical of these articles it was written for the masses and had few technical details. Besides, bet a dollar the people who know from both groups thought it was a bit misguided often (written by Apollo folks tho the intent was sincere.) I currently have a cluster of 4 diskless and one server SUN and from the user level it is quite transparent (the other file system(s) graft into the tree.) I am aware of the non-transparencies in some of the semantics (locking, multiple update) but I think none of these are fatal for now and there are benefits caused by the design (if the server goes down the diskless node in my office just pauses, informs me and when the server comes back continues without a hitch.) I would love to hear about ATT's RFS also (we have a 3B5 and 3B2s and if it is made available they are perfect candidates for this I believe.) I have often thought that a good use of this list is to publish highly technical, brief overviews of new developments as well as bugs etc. Perhaps the protocol to prevent net overdrive is to have people offer to overview with a very short request (unlike this soliliquoy) and see if the interest (and/or objections) is/are there. Anticipating the suggestion that something like net.unix be used I would suggest that the reason to use this list is to try to keep it to a very high technical level (things like administration, operations, kernel changes, design issues etc) rather than 'here kiddies' stuff. Agreed? Another possibility is to form a separate list but I see little benefit from that, I doubt we will be swamped with such things. -Barry Shein, Boston University
david@rsch.wisc.edu (David Parter) (12/20/85)
in <184@isieng.UUCP>, Ronald P. Hughes says: > In response to your inquiry regarding extended file systems under 4.2/4.3: > Here at Integrated Solutions I have implemented TRFS (Transparent Remote File > System) which allows access to remote files. ... > ... Anywhere you can specify a filename or pathname, you can now > specify a remote pathname of the form "/@machinename/pathname", where > pathname is any arbitrary pathname on the remote machine. ... > ... In fact, there are NO new system calls associated with TRFS. > All the standard protection mechanisms apply. how do you resolve remote-access permissions? Is root@a also root@b? is david@a also david@b? david -- -------- david parter University of Wisconsin Systems Lab uucp: ...!{allegra,harvard,ihnp4,seismo, topaz}!uwvax!david arpa: david@rsch.wisc.edu
rees@apollo.uucp (Jim Rees) (12/21/85)
ATT/RFS implements unix file system semantics exactly at the expense of not
being stateless and not caching data in the client. NFS has a stateless
server at the expense of unix file system semantics. In case it isn't
obvious, the big advantage of a stateless server is that it simplifies
recovery after machine or network failure.
Besides, bet a dollar the people who know from
both groups thought it was a bit misguided often (written by Apollo
folks tho the intent was sincere.)
You owe me a buck. The only complaint the AT&T folks had was over a typo
(the RFS mount command came out looking like the NFS mount command).
Actually, I thought we were remarkably restrained about plugging the
Apollo file system. It has the best caching scheme, but falls down on
unix semantics and heterogeneity. It doesn't require you to mount the
other disks on the network, they are all automatically available, always.
The AT&T folks don't consider that an advantage, but then they haven't
tried to put together a 1000 node network yet.gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (12/24/85)
> ATT/RFS implements unix file system semantics exactly at the expense of not > being stateless and not caching data in the client. NFS has a stateless > server at the expense of unix file system semantics. In case it isn't > obvious, the big advantage of a stateless server is that it simplifies > recovery after machine or network failure. AT&T's RFS, I was told, treats a network link going down the same as it would a disk going off-line; there will be an error returned from any subsequent attempt to do I/O to the inaccessible file. Note that full support for UNIX file system semantics is a crucial issue for AT&T UNIX System V systems, which support record locking. The obvious alternative to I/O errors when a net link goes down is to block processes doing remote file I/O over the link until it comes back up; this is probably unwise for record locking systems.
wendyt@isieng.UUCP (Wendy Thrash) (12/27/85)
In <910@brl-tgr.ARPA>, bzs%bostonu.csnet@csnet-relay.arpa (Barry Shein) writes: > Chuq hesitated to overview the SUN NFS for fear of being accused > of commercialism.... > Given the fact that SUN has bent over backwards to get other vendors > to adopt the protocol (making specs and code available) it borders > on silly to feel that this is very commercial.... If SUN has "bent over backwards to get other vendors to adopt the protocol," then our experience must be atypical. We have had _great_ difficulty trying to purchase NFS from them. Have other vendors who compete directly with SUN run into similar problems? Post away, Chuq. We can't buy it, but we can enjoy reading about it. Note: This is not an attack on Chuq; he has been as helpful as he could. Unfortunately, there is a bucket of glue somewhere in the pipeline.
lcc.richard@locus.ucla.edu (Richard Mathews) (12/27/85)
I have one more UNIX compatible system to add to the list of those which
allow for transparent remote file access. As an employee of Locus
Computing Corporation, I will try to avoid making this a commercial and
just stick to the facts.
The LOCUS Distributed Operating System runs on a variety of cpu types
(including VAX) which may all be on the network together. Differences in
architectures are largely hidden from the user. In the VAX version, it is
binary and source compatible with BOTH BSD 4.1 and System V Release 2. The
Berkeley part of it has been enhanced with 4.2 IPC. Programs can take
advantage of both the SysV features and the BSD features at the same time.
A key feature is transparent access to remote files. For example, I can
log in on Fafnir (which is not a VAX), but I will be in my home directory
which is stored on Frodo (which IS a VAX). The name of my home directory
is /u/richard. There is no indication in the name which tells you where
it is stored (I don't have to say anything like /@frodo/u/richard). The
file name "/u/richard" refers to the same file from anywhere on the network.
This is handled by the kernel which maintains a global mount table (Fafnir
knows that Frodo has a file system mounted on /u). Since it is in the
kernel, programs don't have to be recompiled or relinked to use any of the
LOCUS system's features.
An often asked question is "where is the root directory stored?" The
answer is that the root file system is usually replicated, so all sites
can quickly access common programs. Any other file system can also be
replicated. If a replicated file is modified, all copies will be updated
automatically. If a site is down, its copy will be updated when it joins
the network. A site can run without having its own copy of the root by
searching the network for a site willing to act as a file server.
The LOCUS system also allows for transparent access to processes on all
machines. If I am on Fafnir and try to read mail with the "rdm" program,
Fafnir will discover that it cannot run the program because "rdm" is
compiled for a VAX. Fafnir will pick a random VAX to run it on. Pipes,
signals, and terminal access will all work transparently.
If all programs were such that they could only run on one machine type,
that would be a problem. "rdm" is a special case of a program which has
not been ported to our other machines. If you look at our /bin/csh (or
most of the other programs on the root file system) you will find that it
is really two files in one, so that it can run on either Fafnir or on a VAX.
Running processes can also be "migrated" between machines. If I decide
that the load is too high on Fafnir, I can migrate my "make" to any other
machine of the same cpu type. Again, programs do not have to be recompiled
or relinked to take advantage of this.
I do not know when the LOCUS operating system will be publicly available.
Sorry about making this so long, but I got carried away. If you care to
know more, there is a book soon to be published by MIT Press which describes
this system. I beleive the title is something like "The LOCUS Distributed
System Architecture" and the editors are Gerald Popek and Bruce J. Walker.
Richard M. Mathews
Locus Computing Corporation lcc.richard@LOCUS.UCLA.EDU
lcc.richard@UCLA-CS
{ihnp4,trwrb}!lcc!richard
{randvax,sdcrdcf,ucbvax,trwspp}!ucla-cs!lcc!richard
Any opinions here are my own and do not reflect on those of my employer.rick@nyit.UUCP (Rick Ace) (12/30/85)
> > Chuq hesitated to overview the SUN NFS for fear of being accused > > of commercialism.... > > Given the fact that SUN has bent over backwards to get other vendors > > to adopt the protocol (making specs and code available) it borders > > on silly to feel that this is very commercial.... > > If SUN has "bent over backwards to get other vendors to adopt the protocol," > then our experience must be atypical. We have had _great_ difficulty trying > to purchase NFS from them. Have other vendors who compete directly with SUN > run into similar problems? > > Post away, Chuq. We can't buy it, but we can enjoy reading about it. I'm not sure if you'd *want* to buy it. Our site (NYIT) tried to purchase the NFS source from Sun under an educational license agreement. Sun sent us licensing paperwork for the NFS software. Among other things, we were asked to supply the names of five people who would be working with the NFS software, along with their signatures, home addresses, and (dig dis) Social Security numbers. Real fast, I got on the blower to our counsel, who found the request to be extraordinary and somewhat suspicious; he advised us not to comply. And we're not even a competitor :-). Rick Ace Computer Graphics Laboratory New York Institute of Technology Old Westbury, NY 11568 (516) 686-7644 {decvax,seismo}!philabs!nyit!rick
oleg@birtch.UUCP (Oleg Kiselev) (12/31/85)
In article <1066@brl-tgr.ARPA> lcc.richard@locus.ucla.edu (Richard Mathews) writes: >I do not know when the LOCUS operating system will be publicly available. I hear there have been a number of problems with Locus running at UCLA. There have been grumblings about reliability (frequent crashes), high overhead, and general uncomfortableness of the system ( which might have been caused by security mods and attitudes of an educational institution). My experience with Locus was that as an idea it's great : it IS totally transparent. The down side is its speed - you pay a heavy toll for all those nifty features in network sluggishness. -- Disclamer: I don't work here anymore - so they are not responsible for me. +-------------------------------+ Don't bother, I'll find the door! | STAY ALERT! TRUST NO ONE! | Oleg Kiselev. | KEEP YOUR LASER HANDY! |...!{trwrb|scgvaxd}!felix!birtch!oleg --------------------------------+...!{ihnp4|randvax}!ucla-cs!uclapic!oac6!oleg
ron@celerity.UUCP (Ron McDaniels) (01/03/86)
We obtained a license for NFS from Sun with absolutly no difficulty. Moreover,
I would think that we are certainly more likely to be considered a competitor
to Sun than Integrated Solutions. There must be more to the story than has
been told so far. . .
R. L. (Ron) McDaniels
CELERITY COMPUTING . 9692 Via Excelencia Way . San Diego, California . 92126
(619) 271-9940 . {decvax || ucbvax || ihnp4 || philabs}!sdcsvax!celerity!rongmf@hpcnoe.UUCP (01/07/86)
Hewlett-Packard has had a Remote File Access (RFA) protocol available on its HP9000 Series 500 systems on the market since 1983, and it is now available on the Series 300 (680xx-based systems). This RFA maps MOST HP-UX file system calls (section 2) into remote calls if the file specified resides on a remote file system. RFA requires the user to "login" to the remote system prior to using it (this can be done automatically in a ".login" file). All accesses to files on the remote system depend on the permissions associated with the login id used for that machine. HP-UX RFA is not public domain software. George Feinberg (hpfcla!g_feinberg@HPLABS)
toddb@tekcrl.UUCP (Todd Brunhoff) (01/07/86)
I have posted to mod.sources complete software and documentation for installation, maintenance and adjustment of RFS, a public domain, kernel-resident distributed file system, written at Tektronix Computer Research Laboratories* by myself for partial fulfillment of the master's degree program at the University of Denver. It was designed to provide complete transparency with respect to file access and protections for all programs whether they use local or remote files and directories. It has been installed on VAX BSD 4.2 and 4.3 UNIX, Pyramid 4.2/5.0 UNIX, version 2.5, and on a Tektronix internal proprietary workstation, called Magnolia. The instructions are designed in a way that keeps all changes separate from your standard sources, in hope that it will encourage sites to try the installation. The version posted is release 2.0+ (plus bug fixes, easier installation with patch, etc.), for those of you that may have heard of it. I mention this also because I am told that plain old 2.0 will appear on the BSD 4.3 tape under contributed software from U of Colorado at Boulder. Before you ask, it is "stateful". It is completely implemented except for ioctl() and select(). This includes the file locking facility, flock(2), which has been discussed here recently. The raw speed of performing a read(2) or write(2) type of system call remotely is about 25% - 40% that of local speed. Typically, this tends to make programs run about 50% - 90% of normal speed, because most programs spend a majority of their time doing computing, or local I/O (like display to a terminal). This makes it roughly twice as fast as rcp. The bulk of the use it sees here in teklabs, is among 50 or so Magnolias, an 11/780 and an 11/750. Its applications here are largely - distributed program development - distributed libraries for local program development - news - Rand MH mail - distributed font files for troff - distributed man pages And just about any other application that enables us to move large amounts of data off of the workstations and onto the VAX. The nicest win is with distributed program development where you keep all the source for a project on the vax, and each user (having a Magnolia) uses the source via RFS. I am happy to answer questions and redistribute bug fixes. I hope you find this useful. Todd Brunhoff toddb%crl@tektronix.csnet decvax!tektronix!crl!toddb * RFS should not be confused with another completely different (but excellent) implementation from Tektronix available on the 6000 series workstation, called DFS, and done by a separate product group. The work on RFS was designed and written strictly by the author of this paper at about the same time as DFS, and draws none of its implementation details from DFS. RFS is public domain, while DFS is proprietary.
ed@mtxinu.UUCP (Ed Gould) (01/07/86)
In article <161@nyit.UUCP> rick@nyit.UUCP (Rick Ace) writes: > >I'm not sure if you'd *want* to buy it. Our site (NYIT) tried to purchase >the NFS source from Sun under an educational license agreement. Sun >sent us licensing paperwork for the NFS software. Among other things, >we were asked to supply the names of five people who would be working >with the NFS software, along with their signatures, home addresses, and >(dig dis) Social Security numbers. Real fast, I got on the blower to >our counsel, who found the request to be extraordinary and somewhat >suspicious; he advised us not to comply. When we had to sign a similar agreement with Sun, some of us (myself included) refused to give our SSNs. Sun said that it was OK. (Note that it's *illegal* even to ask for a SSN in this context without a disclaimer that the SSN is not required.) The home address part was suspicious but not enough to bother us; asking who would be working on the code seemed reasonable given that they (Sun) wanted more *real* protection than AT&T gets from their trade secret license. -- Ed Gould mt Xinu, 2910 Seventh St., Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146 "A man of quality is not threatened by a woman of equality."
drg@rlvd.UUCP (Duncan Gibson) (01/08/86)
In article <3082@sun.uucp> chuq@sun.uucp (Chuq Von Rospach) writes: > >On more transparent access issues, you can look at the Newcastle connection >(V7 based) which uses a superroot scheme or NFS, which was developed by Sun I don't really know much about NFS, but the Newcastle Connection provides the means of producing a multi-machine Un*x system, which allows remote file access, remote execution, piping between processes running on different machines, etc. transparently. see "The Newcastle Connection, or UNIXes of the World Unite!" by D R Brownbridge, L F Marshall an B Randell in Software - Practice and Experience, Vol. 12, 1147-1162 (1982) -- UUCP: ..!mcvax!ukc!rlvd!drg JANET: drg@uk.ac.rl.vc ARPA: drg%rl.vc@ucl.cs.arpa