Remote File Sharing

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

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
  • 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.
gollark: > By using potatOS, agreeing to be bound by these terms, misusing potatOS, installing potatOS, reading about potatOS, knowing about these terms, knowing anyone who is bound by these terms, disusing potatOS, reading these terms, or thinking of anything related to these terms, you agree to be bound by these terms both until the last stars in the universe burn out and the last black holes evaporate and retroactively, arbitrarily far into the past. This privacy policy may be updated at any time and at all times the latest revision applies.
gollark: > This policy supersedes any applicable federal, national, state, and local laws, regulations and ordinances, policies, international treaties, legal agreements, illegal agreements, or any other agreements that would otherwise apply. If any provision of this policy is found by a court (or other entity) to be unenforceable, it nevertheless remains in force. This organization is not liable and this agreement shall not be construed. We are not responsible for any issue whatsoever at all arising from use of potatOS, potatOS services, anything at all, or otherwise.
gollark: https://osmarks.tk/p3.html#4-4
gollark: > Moreover, Heavpoot (discord ID 160279332454006795, UPID #89VJZ9AK:☭934) is to be considered co-owner of the totality of existence and/or the universe. “Andrew” (Discord ID 543131534685765673, UPID 6ec3837b5260g4b9d█22029e7b474█d63 is at all times incorrect in his beliefs and/or statements, unless this would contradict with other clauses of this policy and/or cause harm to PotatOS or us.
gollark: https://osmarks.tk/p3.html#4-8

See also

References
  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. 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)


This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.