Lines Matching +full:layer +full:- +full:buffer +full:- +full:offset

32 \s-1UNIX\s0\\$1\(dg
34 \(dg \s-1UNIX\s0 is a registered trademark of AT&T.
66 Each design attempts to isolate filesystem-dependent details
102 AT&T's recently-announced Remote File Sharing, RFS [Rifkin86],
108 system [Weinberger84] and two different filesystems used at Carnegie-Mellon
122 with carefully-defined entry points to separate the filesystem from the rest
130 A clean, well-defined interface to the filesystem also allows a single
135 The best-known of these are Sun Microsystems' Virtual File System interface,
155 Each attempts to divide the filesystem into a filesystem-type-independent
156 layer and individual filesystem implementations.
161 at the user-process level, each attempts to be completely transparent
162 except for a few filesystem-related system management programs.
164 system interfaces, and even to retain object-file-level binary compatibility
168 or source-code modification.
177 Most system calls that descend into the file-system dependent layer
179 to the higher-level kernel calling routines.
180 Instead, the filesystem-dependent code completes the requested
181 operation and then executes a non-local goto (\fIlongjmp\fP) to exit the
183 These efforts to avoid modification of main-line kernel code
189 of filesystem-independent and -dependent data structures and operations.
206 No locking may be done in the filesystem-independent layer,
207 and locking in the filesystem-dependent layer may occur only during
208 a single call into that layer.
237 and \fIiget\fP, which locates an inode by number and installs it in the in-core
255 attempt to preserve the inode-oriented interface.
257 for different filesystem types by separating the filesystem-dependent
261 of the old filesystem to be performed in the filesystem-independent
262 layer, with entry points to the individual filesystem implementations to support
263 the type-specific parts of these operations.  Implicit in this interface
272 The vnode contains no filesystem-dependent fields except the pointer
275 permissions, size and timestamps, are maintained by the lower layer.
278 as they may not be up-to-date later on.
290 pathname-to-internal-representation translation.
301 such as the offset in the directory at which the modification will be made.
307 this information is stored in the per-process \fIuser\fP structure
308 by \fInamei\fP for use by a low-level routine called after performing
316 an internal buffer, validating it, interpolating
318 As in 4.3BSD, the name is copied into the buffer in a single call,
323 The filesystem-specific routine translates the name, component by component,
341 A pathname-oriented request other than open may be completed
348 This routine simply calls a new pathname-handling module to allocate
349 a pathname buffer and copy in the pathname (copying a character per call),
352 to the destination file; it copies each pathname component to a local buffer,
355 Per-filesystem \fIlookup\fP routines may translate only one component
369 A system-wide cache of recent translations is maintained.
375 A per-process cache is kept of the directory and offset
380 The entire pathname is copied into a kernel buffer in a single operation,
388 The generalization of the structure may otherwise make an already-expensive
391 from the beta-test version of 4.3BSD.
392 The Sun system uses a name-translation cache generally like that in 4.3BSD.
393 The name cache is a filesystem-independent facility provided for the use
394 of the filesystem-specific lookup routines.
413 by a multi-component name lookup is dramatically larger
449 A prominent example is the filesystem buffer cache.
450 The buffer cache in a standard (System V or 4.3BSD)
456 Sun has modified the buffer cache routines to describe buffers by vnode
462 Use of per-file cache description does not easily accommodate
469 Although the Sun modification makes it possible to use the buffer
471 of the buffer cache is needed.
474 on client systems, thus the buffer cache is probably unmodified.
475 The form of the buffer cache in ULTRIX is unknown to us.
480 to satisfy fill-on-demand page faults.
484 Although the read operation normally bypasses the filesystem buffer cache,
485 consistency must be maintained by checking the buffer cache and copying
491 resolved by reading through the buffer cache, then mapping the cached
493 If the buffer cache or the process pages are changed while the other reference
494 remains, the data would have to be copied (``copy-on-write'').
500 memory system by performing logical-to-physical block number translation
501 when setting up a fill-on-demand image for a process.
515 This entry uses a buffer header (\fIbuf\fP structure)
518 The buffer-style interface is the same as that used by disk drivers internally.
525 the data will be received in a network buffer.
534 the implicit use of user-structure global context,
543 It is also the most general of the three, in that filesystem-specific
544 data and operations are best separated from the generic layer.
560 but, like GFS, uses a 4.3BSD-style name lookup interface.
564 This is especially desired in any system where kernel-mode servers
565 operate as light-weight or interrupt-level processes,
582 to pass these same parameters to filesystem-specific lookup routines,
597  * and to retain per-process context.
609 	caddr_t	ni_pnbuf;		/* pathname buffer */
647 by storing the new directory entry and its offset in the directory
649 This is intended to be opaque to the filesystem-independent levels.
652 may be read-only, etc.
664 For the local filesystem, the per-process directory offset cache
666 A file server could leave the directory offset cache empty,
694 	gid_t   cr_svgid;		/* saved set-group id */
713  * involves scatter-gather, with individual sections
735  * If iov_op is non-null, it is called to implement the copy
769 The structure describing the externally-visible features of a mounted
812 The operations supported by the filesystem-specific layer
844 	long	f_bavail;		/* free blocks avail to non-superuser */
865 (NFS does not allow remotely-mounted file trees to span physical filesystems
976 A pointer to a character buffer used to pass data to or from an \fIioctl\fP.
980 A file offset of type \fIoff_t\fP.
982 A pointer to file offset of type \fIoff_t\fP.
986 A pointer to a file handle buffer.
1024 the file offset and buffer locations.
1027 to return a new file offset token for its current location.
1030 The first, \fIvn_seek\fP, is a concession to record-oriented files
1033 offset, or to return a new offset token relative to an earlier one.
1054  * Vnode attributes.  A field value of -1
1083 between the filesystem-independent and -dependent layers and data structures.
1106 \fISoftware\- Practice and Experience\fP, Vol. 12, pp. 1147-1162, 1982.
1112 pp. 131-150, June, 1985.
1117 pp. 238-247, June, 1986.
1122 \fIUsenix Conference Proceedings\fP, pp. 237-252, June, 1984.
1127 Vol. 2, pp. 181-197,
1133 \fIUsenix Conference Proceedings\fP, pp. 519-531, June, 1985.
1138 pp. 248-259, June, 1986.
1141 Ritchie, D.M. and K. Thompson, ``The Unix Time-Sharing System,''
1142 \fICommunications of the ACM\fP, Vol. 17, pp. 365-375, July, 1974.
1147 pp. 260-269, June, 1986.
1153 pp. 119-130, June, 1985.
1158 \fIProc. 10th Symposium on Operating Systems Principles\fP, pp. 35-50,