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.
See also
References
- ↑ Rifkin, Andrew P.; Forbes, Michael P.; Hamilton, Richard L.; Sabrio, Michael; Shah, Suryakanta; Yueh, Kang (1987). "RFS architectural overview". 7.
- ↑ 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
- ↑ Dennis M. Ritchie, A Stream Input-Output System, Bell Laboratories Technical Journal 63(8) (October 1984)
 |  |
