Lines Matching full:filesystem

40 Toward a Compatible Filesystem Interface
54 several stylized interfaces between the filesystem implementation
63 Notable among these are Sun Microsystems' Virtual Filesystem interface (VFS)
66 Each design attempts to isolate filesystem-dependent details
75 and uses a different set of primitive operations provided by the filesystem.
76 The current study compares the various filesystem interfaces.
80 As a result of this comparison, a proposal for a new filesystem interface
87 as an early step toward convergence on a compatible filesystem interface.
103 the LOCUS distributed filesystem [Walker85],
104 and Masscomp's extended filesystem [Cole85].
106 for internal use, notably the network filesystem in the Eighth Edition
119 These circumstances make it highly desirable to be able to transport filesystem
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
131 system to support multiple local filesystem types.
133 For reasons such as these, several filesystem interfaces have been used
155 Each attempts to divide the filesystem into a filesystem-type-independent
156 layer and individual filesystem implementations.
162 except for a few filesystem-related system management programs.
171 and exact semantics of their previous filesystem,
178 of a filesystem other than the standard local filesystem do not return
180 Instead, the filesystem-dependent code completes the requested
189 of filesystem-independent and -dependent data structures and operations.
190 The semantics of the filesystem are largely retained for local operations,
193 The filesystem implementations are not required to support the same
199 filesystem behavior are difficult to achieve using the VFS interface,
203 A major design objective of Sun's network filesystem,
206 No locking may be done in the filesystem-independent layer,
207 and locking in the filesystem-dependent layer may occur only during
215 but has emphasized clean separation of the layers within the filesystem
221 Differences among filesystem interfaces
223 The existing filesystem interfaces may be characterized
229 filesystem [Ritchie74],
230 the basic object used by the filesystem is the inode, or index node.
233 Inodes are identified by the filesystem device number and the index within
234 the filesystem.
235 The major entry points to the filesystem are \fInamei\fP,
236 which translates a filesystem pathname into the underlying inode,
247 Modified inodes are automatically written back to the filesystem
250 the same general scheme is used in the faster filesystem in 4.2BSD
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
265 index within a filesystem.
272 The vnode contains no filesystem-dependent fields except the pointer
273 to the set of operations implemented by the filesystem.
305 In the System V filesystem, as in previous versions of
320 After determining the type of the filesystem at the start of translation
321 (the current directory or root directory), it calls the filesystem's
323 The filesystem-specific routine translates the name, component by component,
327 the correct translation routine for the next filesystem.
331 but the latter scheme allows mount points within a remote filesystem
339 If it detects that a mount point crosses to a remote filesystem,
353 then calls the filesystem \fIlookup\fP entry to locate the vnode
355 Per-filesystem \fIlookup\fP routines may translate only one component
387 within a more generalized filesystem framework.
393 The name cache is a filesystem-independent facility provided for the use
394 of the filesystem-specific lookup routines.
401 than (local filesystem) vnodes, and the cache distorts the normal reference
403 As the name cache references overflow the local filesystem inode table,
419 As the filesystem operations are more stylized and broken into separate
422 processes using the same filesystem objects.
425 to the filesystem.
434 This problem will always exist in a stateless filesystem,
444 filesystem and require generalization for use by other filesystem types.
445 For filesystem implementations to be portable,
449 A prominent example is the filesystem buffer cache.
454 This works well for the local filesystem, but has obvious problems
461 and the block numbers are filesystem physical blocks.
473 The RFS filesystem used by AT&T does not currently cache data blocks
477 Another subsystem that has a large interaction with the filesystem
479 The virtual memory system must read data from the filesystem
484 Although the read operation normally bypasses the filesystem buffer cache,
497 with the new filesystem framework.
498 Both the Sun and AT&T filesystem interfaces
499 provide entry points to the filesystem for optimization of the virtual
504 filesystem.
507 If the filesystem is local, it returns the private vnode for the block device
513 for ``raw'' reads from a filesystem device,
529 In either case, it should be possible to use the standard filesystem
533 filesystem implementation include kernel memory allocation,
543 It is also the most general of the three, in that filesystem-specific
551 to be translated in a single call to the specific filesystem
557 Accordingly, a new filesystem interface has been devised to avoid
569 through the filesystem interface,
573 The proposed filesystem interface is described very tersely here.
582 to pass these same parameters to filesystem-specific lookup routines,
585 For creation or deletion requests, the parameters to the filesystem operation
644 CREATE and DELETE allow the filesystem to ensure consistency
645 by locking the parent inode (private to the filesystem),
646 and (for the local filesystem) to avoid duplicate directory scans
649 This is intended to be opaque to the filesystem-independent levels.
651 by the intended operation; permission may be denied, the filesystem
653 Therefore, an entry point to the filesystem is provided
664 For the local filesystem, the per-process directory offset cache
670 Several other data structures are used in the filesystem operations.
672 to the filesystem.
698 A final structure used by the filesystem interface is the \fIuio\fP
702 It is used in the read and write entries to the filesystem.
761 File and filesystem operations
763 With the introduction of the data structures used by the filesystem
764 operations, the complete list of filesystem entry points may be listed.
770 filesystem, \fIvfs\fP, is:
800 \fB+\fP #define VFS_NOEXEC 0x02 /* can't exec from filesystem */
812 The operations supported by the filesystem-specific layer
813 on an individual filesystem are:
838 \fB!\fP short f_type; /* type of filesystem */
849 \fB+\fP char *f_mntfromname; /* mounted filesystem */
859 \fIvfs_statfs\fP accepts a vnode as well as filesystem identifier,
860 as the information may not be uniform throughout a filesystem.
874 Finally, the external form of a filesystem object, the \fIvnode\fP, is:
1020 The two entries may be identical for any given filesystem;
1032 It allows the filesystem to verify that a seek leaves a file at a sensible
1041 changes for short periods of time if the filesystem implementation allows it.
1044 and may not be used to construct atomic operations from other filesystem
1080 The Sun VFS filesystem interface is the most widely used generic
1081 filesystem interface.
1083 between the filesystem-independent and -dependent layers and data structures.
1090 of the filesystem layering, it will be advanced as a model interface.
1094 The filesystem interface described here is derived from Sun's VFS interface.
1151 ``Design and Implementation of the Sun Network Filesystem,''
1162 Walker, B.J. and S.H. Kiser, ``The LOCUS Distributed Filesystem,''