Jump to content

Remote File Sharing: Difference between revisions

Edit links
From Wikipedia, the free encyclopedia
Browse history interactively
← Previous edit
Content deleted Content added
VisualWikitext
List of ppl involved in the development of RFS
Adding local short description: "Computer program for sharing resources", overriding Wikidata description "discontinued distributed file system developed by AT&T in the 1980s"
 
(42 intermediate revisions by 30 users not shown)
Line 1: Line 1:
{{Short description|Computer program for sharing resources}}
The Remote File System (RFS) was a file access protocol developed by [[AT&T]] in the 1980s. It was
'''Remote File Sharing''' ('''RFS''') is a [[Unix]] operating system component for sharing resources, such as files, devices, and file system directories, across a network, in a network-independent manner, similar to a [[distributed file system]]. It was developed at [[Bell Laboratories]] of [[AT&T Corporation|AT&T]] in the 1980s, and was first delivered with [[UNIX System V]] Release 3 (SVR3).<ref>{{cite conference
first delivered with [[Unix|UNIX]] System V Release 3. Compared to [[Network_File_System|NFS]] it was superior on purely logical grounds, a ''true'' network file system which preserved [[UNIX semantics]] across the network. Unlike NFS the RFS daemon maintains state to keep track of how many times a file has been opened, if any process has locked the file, etc. RFS was a product from Bell Laboratories. People involved in the creation of RFS: Andrew P. Rifkin, Michael P. Forbes, Richard L. Hamilton, Michael Sabrio, Suryakanta Shah, and Kang Yueh.
| last1 = Rifkin
| first1 = Andrew P.
| last2 = Forbes
| first2 = Michael P.
| last3 = Hamilton
| first3 = Richard L.
| last4 = Sabrio
| first4 = Michael
| last5 = Shah
| first5 = Suryakanta
| last6 = Yueh
| first6 = Kang
| title = RFS architectural overview
| book-title = Australian UNIX systems User Group Newsletter
| volume = 7
| number = 4–5
| year = 1987
}}</ref> RFS relied on the STREAMS Transport Provider Interface feature of this operating system. It was also included in UNIX System V Release 4, but as that also included the [[Network File System]] (NFS) which was based on [[Internet protocol suite|TCP/IP]] and more widely supported in the computing industry, RFS was little used. Some licensees of AT&T UNIX System V Release 4 did not include RFS support in SVR4 distributions, and [[Sun Microsystems]] removed it from [[Solaris (operating system)|Solaris]] 2.4.


== Features ==
==Features==
The basic application architecture of RFS is the [[client–server model]], in which a participating host may be a server as well as a client, simultaneously. It was based on different design decisions, in comparison to the Network File System (NFS). Instead of focusing on reliable operation in the presence of failures, it focused on preserving UNIX file system semantics across the network. This enabled the system to provide remote access to hardware resources located on an RFS server. Unlike NFS (before version 4), the RFS [[server (computing)|server]] maintains state to keep track of how many times a file has been opened, or the [[Lock (computer science)|locks]] established on a file or device.
* Provides complete UNIX/POSIX file semantics. (File locking, etc)
* Allows mounting of devices across the network (e.g ''/dev/cdrom'' can be accessed remotely)
* Transparent access to files. Users needn't know where a file is located.


RFS provides complete UNIX/POSIX file semantics for all file types, including special devices, and named pipes. It supports access controls and record and [[file locking]] of remote files in a transparent manner as if the shared files are local. This permitted binary application compatibility when involving network resources.<ref>A. P. Rifkin, M. P. Forbes, R. L. Hamilton, Michail Sabrio, S. Shah, and K. Yueh, ''RFS Architectural Overview'', USENIX Conference Proceedings (June 1986), Atlanta, GA</ref> It allows the mounting of devices across the network. For example, ''/dev/cdrom'' can be accessed remotely, as if it were a local resource. Access to any specific file or a file system directory is transparent across the network, so that users do not need to know where a file is actually located.
⚫
== Remote system call interface ==

RFS is implemented independently of the underlying network technology. For this it relies on the System V STREAMS mechanism using the Transport Provider Interface.<ref>Dennis M. Ritchie, ''A Stream Input-Output System'', Bell Laboratories Technical Journal 63(8) (October 1984)</ref>

⚫
==Remote system call interface==
{{colbegin}}
* ACCESS
* ACCESS
* SYSACCT
* SYSACCT
Line 19: Line 40:
* EXECE Execute a file with an environment
* EXECE Execute a file with an environment
* FCNTL
* FCNTL
* FSTAT Stat a file using a file descriptor
* FSTAT Stat a file using a [[file descriptor]]
* FSTATFS Stat a file system using a file descriptor
* FSTATFS Stat a file system using a file descriptor
* IOCTL
* IOCTL
Line 47: Line 68:
* IUPDATE Update a remote inode
* IUPDATE Update a remote inode
* UPDATE Write modified buffers back to disk.
* UPDATE Write modified buffers back to disk.
{{colend}}


==See also==
⚫
{{Compu-storage-stub}}
* [[AppleTalk]]
* [[Samba (software)|Samba]]
* [[Server Message Block]]
* [[WebDAV]]

==References==
{{reflist}}


[[Category:Internet protocols]]
[[Category:Internet protocols]]
[[Category:Network file systems]]
[[Category:Network file systems]]
[[Category:Network-related software]]
[[Category:Internet Protocol based network software]]
[[Category:UNIX System V]]


⚫
{{Compu-storage-stub}}

Latest revision as of 21:37, 7 December 2024

Remote File Sharing (RFS) is a Unix operating system component for sharing resources, such as files, devices, and file system directories, across a network, in a network-independent manner, similar to a distributed file system. It was developed at Bell Laboratories of AT&T in the 1980s, and was first delivered with UNIX System V Release 3 (SVR3).[1] RFS relied on the STREAMS Transport Provider Interface feature of this operating system. It was also included in UNIX System V Release 4, but as that also included the Network File System (NFS) which was based on TCP/IP and more widely supported in the computing industry, RFS was little used. Some licensees of AT&T UNIX System V Release 4 did not include RFS support in SVR4 distributions, and Sun Microsystems removed it from Solaris 2.4.

Features

[edit]

The basic application architecture of RFS is the client–server model, in which a participating host may be a server as well as a client, simultaneously. It was based on different design decisions, in comparison to the Network File System (NFS). Instead of focusing on reliable operation in the presence of failures, it focused on preserving UNIX file system semantics across the network. This enabled the system to provide remote access to hardware resources located on an RFS server. Unlike NFS (before version 4), the RFS server maintains state to keep track of how many times a file has been opened, or the locks established on a file or device.

RFS provides complete UNIX/POSIX file semantics for all file types, including special devices, and named pipes. It supports access controls and record and file locking of remote files in a transparent manner as if the shared files are local. This permitted binary application compatibility when involving network resources.[2] It allows the mounting of devices across the network. For example, /dev/cdrom can be accessed remotely, as if it were a local resource. Access to any specific file or a file system directory is transparent across the network, so that users do not need to know where a file is actually located.

RFS is implemented independently of the underlying network technology. For this it relies on the System V STREAMS mechanism using the Transport Provider Interface.[3]

Remote system call interface

[edit]
  • ACCESS
  • SYSACCT
  • CHDIR Change directory
  • CHMOD Change file mode
  • CHOWN Change file owner
  • CHROOT
  • CLOSE Close a file
  • CREAT Create a file
  • EXEC Execute a file
  • EXECE Execute a file with an environment
  • FCNTL
  • FSTAT Stat a file using a file descriptor
  • FSTATFS Stat a file system using a file descriptor
  • IOCTL
  • LINK First half of link() operation
  • LINK1 Second half of link() operation
  • MKNOD Make block or character special file
  • OPEN Open a file
  • READ Read from a file
  • SEEK Seek on a file
  • STAT Stat a file using pathname
  • STATFS Stat a file system using pathname
  • UNLINK
  • UTIME
  • UTSSYS Return information about a mounted files
  • WRITE
  • GETDENTS Read directory entries in a file system
  • MKDIR
  • RMDIR
  • SRMOUNT Server side of remote mount
  • SRUMOUNT Server side of remote unmount
  • COREDUMP Dump core request
  • WRITEI Internal form of write system call
  • READI Internal form of read system call
  • RSIGNAL Sendremote signal
  • SYNCTIME Synchronize time between machines
  • IPUT Free a remote inode
  • IUPDATE Update a remote inode
  • UPDATE Write modified buffers back to disk.

See also

[edit]

References

[edit]
  1. ^ Rifkin, Andrew P.; Forbes, Michael P.; Hamilton, Richard L.; Sabrio, Michael; Shah, Suryakanta; Yueh, Kang (1987). "RFS architectural overview". Australian UNIX systems User Group Newsletter. Vol. 7.
  2. ^ A. P. Rifkin, M. P. Forbes, R. L. Hamilton, Michail Sabrio, S. Shah, and K. Yueh, RFS Architectural Overview, USENIX Conference Proceedings (June 1986), Atlanta, GA
  3. ^ Dennis M. Ritchie, A Stream Input-Output System, Bell Laboratories Technical Journal 63(8) (October 1984)


Stub icon

This computer-storage-related article is a stub. You can help Wikipedia by expanding it.

Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Remote_File_Sharing&oldid=1261765467"