| fsinterface.ms (21673) | fsinterface.ms (22818) |
|---|---|
| 1.\" Copyright (c) 1986 The Regents of the University of California. 2.\" All rights reserved. 3.\" 4.\" Redistribution and use in source and binary forms, with or without 5.\" modification, are permitted provided that the following conditions 6.\" are met: 7.\" 1. Redistributions of source code must retain the above copyright 8.\" notice, this list of conditions and the following disclaimer. --- 16 unchanged lines hidden (view full) --- 25.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 26.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 27.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 28.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 29.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 30.\" SUCH DAMAGE. 31.\" 32.\" @(#)fsinterface.ms 1.4 (Berkeley) 4/16/91 | 1.\" Copyright (c) 1986 The Regents of the University of California. 2.\" All rights reserved. 3.\" 4.\" Redistribution and use in source and binary forms, with or without 5.\" modification, are permitted provided that the following conditions 6.\" are met: 7.\" 1. Redistributions of source code must retain the above copyright 8.\" notice, this list of conditions and the following disclaimer. --- 16 unchanged lines hidden (view full) --- 25.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 26.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 27.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 28.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 29.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 30.\" SUCH DAMAGE. 31.\" 32.\" @(#)fsinterface.ms 1.4 (Berkeley) 4/16/91 |
| 33.\" $FreeBSD: head/share/doc/papers/fsinterface/fsinterface.ms 21673 1997-01-14 07:20:47Z jkh $ | 33.\" $FreeBSD: head/share/doc/papers/fsinterface/fsinterface.ms 22818 1997-02-17 00:07:54Z wosch $ |
| 34.\" 35.if \nv .rm CM 36.de UX 37.ie \\n(UX \s-1UNIX\s0\\$1 38.el \{\ 39\s-1UNIX\s0\\$1\(dg 40.FS 41\(dg \s-1UNIX\s0 is a registered trademark of AT&T. --- 46 unchanged lines hidden (view full) --- 88is advanced that includes the best features of the existing implementations. 89The proposal adopts the calling convention for name lookup introduced 90in 4.3BSD, but is otherwise closely related to Sun's VFS. 91A prototype implementation is now being developed at Berkeley. 92This proposal and the rationale underlying its development 93have been presented to major software vendors 94as an early step toward convergence on a compatible filesystem interface. 95.AE | 34.\" 35.if \nv .rm CM 36.de UX 37.ie \\n(UX \s-1UNIX\s0\\$1 38.el \{\ 39\s-1UNIX\s0\\$1\(dg 40.FS 41\(dg \s-1UNIX\s0 is a registered trademark of AT&T. --- 46 unchanged lines hidden (view full) --- 88is advanced that includes the best features of the existing implementations. 89The proposal adopts the calling convention for name lookup introduced 90in 4.3BSD, but is otherwise closely related to Sun's VFS. 91A prototype implementation is now being developed at Berkeley. 92This proposal and the rationale underlying its development 93have been presented to major software vendors 94as an early step toward convergence on a compatible filesystem interface. 95.AE |
| 96.SH | 96.NH |
| 97Introduction 98.PP 99As network communications and workstation environments 100became common elements in 101.UX 102systems, several vendors of 103.UX 104systems have designed and built network file systems --- 44 unchanged lines hidden (view full) --- 149system by Digital [Rodriguez86]. 150There are numerous differences among these designs. 151The differences may be understood from the varying philosophies 152and design goals of the groups involved, from the systems under which 153the implementations were done, and from the filesystems originally targetted 154by the designs. 155These differences are summarized in the following sections 156within the limitations of the published specifications. | 97Introduction 98.PP 99As network communications and workstation environments 100became common elements in 101.UX 102systems, several vendors of 103.UX 104systems have designed and built network file systems --- 44 unchanged lines hidden (view full) --- 149system by Digital [Rodriguez86]. 150There are numerous differences among these designs. 151The differences may be understood from the varying philosophies 152and design goals of the groups involved, from the systems under which 153the implementations were done, and from the filesystems originally targetted 154by the designs. 155These differences are summarized in the following sections 156within the limitations of the published specifications. |
| 157.SH | 157.NH |
| 158Design goals 159.PP 160There are several design goals which, in varying degrees, 161have driven the various designs. 162Each attempts to divide the filesystem into a filesystem-type-independent 163layer and individual filesystem implementations. 164The division between these layers occurs at somewhat different places 165in these systems, reflecting different views of the diversity and types --- 53 unchanged lines hidden (view full) --- 219this goal tends to be in conflict with the goals of complete semantic 220consistency, compatibility and modularity. 221Sun has chosen performance over modularity in some areas, 222but has emphasized clean separation of the layers within the filesystem 223at the expense of performance. 224Although the performance of RFS is yet to be seen, 225AT&T seems to have considered compatibility far more important than modularity 226or performance. | 158Design goals 159.PP 160There are several design goals which, in varying degrees, 161have driven the various designs. 162Each attempts to divide the filesystem into a filesystem-type-independent 163layer and individual filesystem implementations. 164The division between these layers occurs at somewhat different places 165in these systems, reflecting different views of the diversity and types --- 53 unchanged lines hidden (view full) --- 219this goal tends to be in conflict with the goals of complete semantic 220consistency, compatibility and modularity. 221Sun has chosen performance over modularity in some areas, 222but has emphasized clean separation of the layers within the filesystem 223at the expense of performance. 224Although the performance of RFS is yet to be seen, 225AT&T seems to have considered compatibility far more important than modularity 226or performance. |
| 227.SH | 227.NH |
| 228Differences among filesystem interfaces 229.PP 230The existing filesystem interfaces may be characterized 231in several ways. 232Each system is centered around a few data structures or objects, 233along with a set of primitives for performing operations upon these objects. 234In the original 235.UX --- 49 unchanged lines hidden (view full) --- 285as they may not be up-to-date later on. 286The vnode operations do not include a corollary for \fIiget\fP; 287the only external interface for obtaining vnodes for specific files 288is the name lookup operation. 289(Separate procedures are provided outside of this interface 290that obtain a ``file handle'' for a vnode which may be given 291to a client by a server, such that the vnode may be retrieved 292upon later presentation of the file handle.) | 228Differences among filesystem interfaces 229.PP 230The existing filesystem interfaces may be characterized 231in several ways. 232Each system is centered around a few data structures or objects, 233along with a set of primitives for performing operations upon these objects. 234In the original 235.UX --- 49 unchanged lines hidden (view full) --- 285as they may not be up-to-date later on. 286The vnode operations do not include a corollary for \fIiget\fP; 287the only external interface for obtaining vnodes for specific files 288is the name lookup operation. 289(Separate procedures are provided outside of this interface 290that obtain a ``file handle'' for a vnode which may be given 291to a client by a server, such that the vnode may be retrieved 292upon later presentation of the file handle.) |
| 293.SH | 293.NH |
| 294Name translation issues 295.PP 296Each of the systems described include a mechanism for performing 297pathname-to-internal-representation translation. 298The style of the name translation function is very different in all 299three systems. 300As described above, the AT&T and DEC systems retain the \fInamei\fP function. 301The two are quite different, however, as the ULTRIX interface uses --- 136 unchanged lines hidden (view full) --- 438The call will either fail unexpectedly, as the target is of the wrong type, 439or the generic creation routine will have to note the error 440and restart the operation from the lookup. 441This problem will always exist in a stateless filesystem, 442but the VFS interface forces all filesystems to share the problem. 443This restriction against locking between calls also 444forces duplication of work during file creation and deletion. 445This is considered unacceptable. | 294Name translation issues 295.PP 296Each of the systems described include a mechanism for performing 297pathname-to-internal-representation translation. 298The style of the name translation function is very different in all 299three systems. 300As described above, the AT&T and DEC systems retain the \fInamei\fP function. 301The two are quite different, however, as the ULTRIX interface uses --- 136 unchanged lines hidden (view full) --- 438The call will either fail unexpectedly, as the target is of the wrong type, 439or the generic creation routine will have to note the error 440and restart the operation from the lookup. 441This problem will always exist in a stateless filesystem, 442but the VFS interface forces all filesystems to share the problem. 443This restriction against locking between calls also 444forces duplication of work during file creation and deletion. 445This is considered unacceptable. |
| 446.SH | 446.NH |
| 447Support facilities and other interactions 448.PP 449Several support facilities are used by the current 450.UX 451filesystem and require generalization for use by other filesystem types. 452For filesystem implementations to be portable, 453it is desirable that these modified support facilities 454should also have a uniform interface and --- 83 unchanged lines hidden (view full) --- 538.PP 539Other issues that must be considered in devising a portable 540filesystem implementation include kernel memory allocation, 541the implicit use of user-structure global context, 542which may create problems with reentrancy, 543the style of the system call interface, 544and the conventions for synchronization 545(sleep/wakeup, handling of interrupted system calls, semaphores). | 447Support facilities and other interactions 448.PP 449Several support facilities are used by the current 450.UX 451filesystem and require generalization for use by other filesystem types. 452For filesystem implementations to be portable, 453it is desirable that these modified support facilities 454should also have a uniform interface and --- 83 unchanged lines hidden (view full) --- 538.PP 539Other issues that must be considered in devising a portable 540filesystem implementation include kernel memory allocation, 541the implicit use of user-structure global context, 542which may create problems with reentrancy, 543the style of the system call interface, 544and the conventions for synchronization 545(sleep/wakeup, handling of interrupted system calls, semaphores). |
| 546.SH | 546.NH |
| 547The Berkeley Proposal 548.PP 549The Sun VFS interface has been most widely used of the three described here. 550It is also the most general of the three, in that filesystem-specific 551data and operations are best separated from the generic layer. 552Although it has several disadvantages which were described above, 553most of them may be corrected with minor changes to the interface 554(and, in a few areas, philosophical changes). --- 205 unchanged lines hidden (view full) --- 760 * Segment flag values. 761 */ 762enum uio_seg { 763 UIO_USERSPACE, /* from user data space */ 764 UIO_SYSSPACE, /* from system space */ 765 UIO_USERISPACE /* from user I space */ 766}; 767.DE | 547The Berkeley Proposal 548.PP 549The Sun VFS interface has been most widely used of the three described here. 550It is also the most general of the three, in that filesystem-specific 551data and operations are best separated from the generic layer. 552Although it has several disadvantages which were described above, 553most of them may be corrected with minor changes to the interface 554(and, in a few areas, philosophical changes). --- 205 unchanged lines hidden (view full) --- 760 * Segment flag values. 761 */ 762enum uio_seg { 763 UIO_USERSPACE, /* from user data space */ 764 UIO_SYSSPACE, /* from system space */ 765 UIO_USERISPACE /* from user I space */ 766}; 767.DE |
| 768.SH | 768.NH |
| 769File and filesystem operations 770.PP 771With the introduction of the data structures used by the filesystem 772operations, the complete list of filesystem entry points may be listed. 773As noted, they derive mostly from the Sun VFS interface. 774Lines marked with \fB+\fP are additions to the Sun definitions; 775lines marked with \fB!\fP are modified from VFS. 776.PP --- 300 unchanged lines hidden (view full) --- 1077 struct timeval va_atime; /* time of last access */ 1078 struct timeval va_mtime; /* time of last modification */ 1079 struct timeval va_ctime; /* time file changed */ 1080 dev_t va_rdev; /* device the file represents */ 1081 u_long va_bytes; /* bytes of disk space held by file */ 1082\fB+\fP u_long va_bytes1; /* reserved if va_bytes not a quad */ 1083}; 1084.DE | 769File and filesystem operations 770.PP 771With the introduction of the data structures used by the filesystem 772operations, the complete list of filesystem entry points may be listed. 773As noted, they derive mostly from the Sun VFS interface. 774Lines marked with \fB+\fP are additions to the Sun definitions; 775lines marked with \fB!\fP are modified from VFS. 776.PP --- 300 unchanged lines hidden (view full) --- 1077 struct timeval va_atime; /* time of last access */ 1078 struct timeval va_mtime; /* time of last modification */ 1079 struct timeval va_ctime; /* time file changed */ 1080 dev_t va_rdev; /* device the file represents */ 1081 u_long va_bytes; /* bytes of disk space held by file */ 1082\fB+\fP u_long va_bytes1; /* reserved if va_bytes not a quad */ 1083}; 1084.DE |
| 1085.SH | 1085.NH |
| 1086Conclusions 1087.PP 1088The Sun VFS filesystem interface is the most widely used generic 1089filesystem interface. 1090Of the interfaces examined, it creates the cleanest separation 1091between the filesystem-independent and -dependent layers and data structures. 1092It has several flaws, but it is felt that certain changes in the interface 1093can ameliorate most of them. 1094The interface proposed here includes those changes. 1095The proposed interface is now being implemented by the Computer Systems 1096Research Group at Berkeley. 1097If the design succeeds in improving the flexibility and performance 1098of the filesystem layering, it will be advanced as a model interface. | 1086Conclusions 1087.PP 1088The Sun VFS filesystem interface is the most widely used generic 1089filesystem interface. 1090Of the interfaces examined, it creates the cleanest separation 1091between the filesystem-independent and -dependent layers and data structures. 1092It has several flaws, but it is felt that certain changes in the interface 1093can ameliorate most of them. 1094The interface proposed here includes those changes. 1095The proposed interface is now being implemented by the Computer Systems 1096Research Group at Berkeley. 1097If the design succeeds in improving the flexibility and performance 1098of the filesystem layering, it will be advanced as a model interface. |
| 1099.SH | 1099.NH |
| 1100Acknowledgements 1101.PP 1102The filesystem interface described here is derived from Sun's VFS interface. 1103It also includes features similar to those of DEC's GFS interface. 1104We are indebted to members of the Sun and DEC system groups 1105for long discussions of the issues involved. 1106.br 1107.ne 2i | 1100Acknowledgements 1101.PP 1102The filesystem interface described here is derived from Sun's VFS interface. 1103It also includes features similar to those of DEC's GFS interface. 1104We are indebted to members of the Sun and DEC system groups 1105for long discussions of the issues involved. 1106.br 1107.ne 2i |
| 1108.SH | 1108.NH |
| 1109References 1110 1111.IP Brownbridge82 \w'Satyanarayanan85\0\0'u 1112Brownbridge, D.R., L.F. Marshall, B. Randell, 1113``The Newcastle Connection, or UNIXes of the World Unite!,'' 1114\fISoftware\- Practice and Experience\fP, Vol. 12, pp. 1147-1162, 1982. 1115 1116.IP Cole85 --- 61 unchanged lines hidden --- | 1109References 1110 1111.IP Brownbridge82 \w'Satyanarayanan85\0\0'u 1112Brownbridge, D.R., L.F. Marshall, B. Randell, 1113``The Newcastle Connection, or UNIXes of the World Unite!,'' 1114\fISoftware\- Practice and Experience\fP, Vol. 12, pp. 1147-1162, 1982. 1115 1116.IP Cole85 --- 61 unchanged lines hidden --- |