![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to 5.t CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / share / doc / smm / 14.fastfs|
Return to 5.t CVS log | Up to [CSRG BSD Unix] / 43BSDReno / share / doc / smm / 14.fastfs |
1.1 root 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 are permitted
5: .\" provided that the above copyright notice and this paragraph are
6: .\" duplicated in all such forms and that any documentation,
7: .\" advertising materials, and other materials related to such
8: .\" distribution and use acknowledge that the software was developed
9: .\" by the University of California, Berkeley. The name of the
10: .\" University may not be used to endorse or promote products derived
11: .\" from this software without specific prior written permission.
12: .\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
13: .\" IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
14: .\" WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
15: .\"
16: .\" @(#)5.t 6.2 (Berkeley) 3/7/89
17: .\"
18: .ds RH Functional enhancements
19: .NH
20: File system functional enhancements
21: .PP
22: The performance enhancements to the
23: UNIX file system did not require
24: any changes to the semantics or
25: data structures visible to application programs.
26: However, several changes had been generally desired for some
27: time but had not been introduced because they would require users to
28: dump and restore all their file systems.
29: Since the new file system already
30: required all existing file systems to
31: be dumped and restored,
32: these functional enhancements were introduced at this time.
33: .NH 2
34: Long file names
35: .PP
36: File names can now be of nearly arbitrary length.
37: Only programs that read directories are affected by this change.
38: To promote portability to UNIX systems that
39: are not running the new file system, a set of directory
40: access routines have been introduced to provide a consistent
41: interface to directories on both old and new systems.
42: .PP
43: Directories are allocated in 512 byte units called chunks.
44: This size is chosen so that each allocation can be transferred
45: to disk in a single operation.
46: Chunks are broken up into variable length records termed
47: directory entries. A directory entry
48: contains the information necessary to map the name of a
49: file to its associated inode.
50: No directory entry is allowed to span multiple chunks.
51: The first three fields of a directory entry are fixed length
52: and contain: an inode number, the size of the entry, and the length
53: of the file name contained in the entry.
54: The remainder of an entry is variable length and contains
55: a null terminated file name, padded to a 4 byte boundary.
56: The maximum length of a file name in a directory is
57: currently 255 characters.
58: .PP
59: Available space in a directory is recorded by having
60: one or more entries accumulate the free space in their
61: entry size fields. This results in directory entries
62: that are larger than required to hold the
63: entry name plus fixed length fields. Space allocated
64: to a directory should always be completely accounted for
65: by totaling up the sizes of its entries.
66: When an entry is deleted from a directory,
67: its space is returned to a previous entry
68: in the same directory chunk by increasing the size of the
69: previous entry by the size of the deleted entry.
70: If the first entry of a directory chunk is free, then
71: the entry's inode number is set to zero to indicate
72: that it is unallocated.
73: .NH 2
74: File locking
75: .PP
76: The old file system had no provision for locking files.
77: Processes that needed to synchronize the updates of a
78: file had to use a separate ``lock'' file.
79: A process would try to create a ``lock'' file.
80: If the creation succeeded, then the process
81: could proceed with its update;
82: if the creation failed, then the process would wait and try again.
83: This mechanism had three drawbacks.
84: Processes consumed CPU time by looping over attempts to create locks.
85: Locks left lying around because of system crashes had
86: to be manually removed (normally in a system startup command script).
87: Finally, processes running as system administrator
88: are always permitted to create files,
89: so were forced to use a different mechanism.
90: While it is possible to get around all these problems,
91: the solutions are not straight forward,
92: so a mechanism for locking files has been added.
93: .PP
94: The most general schemes allow multiple processes
95: to concurrently update a file.
96: Several of these techniques are discussed in [Peterson83].
97: A simpler technique is to serialize access to a file with locks.
98: To attain reasonable efficiency,
99: certain applications require the ability to lock pieces of a file.
100: Locking down to the byte level has been implemented in the
101: Onyx file system by [Bass81].
102: However, for the standard system applications,
103: a mechanism that locks at the granularity of a file is sufficient.
104: .PP
105: Locking schemes fall into two classes,
106: those using hard locks and those using advisory locks.
107: The primary difference between advisory locks and hard locks is the
108: extent of enforcement.
109: A hard lock is always enforced when a program tries to
110: access a file;
111: an advisory lock is only applied when it is requested by a program.
112: Thus advisory locks are only effective when all programs accessing
113: a file use the locking scheme.
114: With hard locks there must be some override
115: policy implemented in the kernel.
116: With advisory locks the policy is left to the user programs.
117: In the UNIX system, programs with system administrator
118: privilege are allowed override any protection scheme.
119: Because many of the programs that need to use locks must
120: also run as the system administrator,
121: we chose to implement advisory locks rather than
122: create an additional protection scheme that was inconsistent
123: with the UNIX philosophy or could
124: not be used by system administration programs.
125: .PP
126: The file locking facilities allow cooperating programs to apply
127: advisory
128: .I shared
129: or
130: .I exclusive
131: locks on files.
132: Only one process may have an exclusive
133: lock on a file while multiple shared locks may be present.
134: Both shared and exclusive locks cannot be present on
135: a file at the same time.
136: If any lock is requested when
137: another process holds an exclusive lock,
138: or an exclusive lock is requested when another process holds any lock,
139: the lock request will block until the lock can be obtained.
140: Because shared and exclusive locks are advisory only,
141: even if a process has obtained a lock on a file,
142: another process may access the file.
143: .PP
144: Locks are applied or removed only on open files.
145: This means that locks can be manipulated without
146: needing to close and reopen a file.
147: This is useful, for example, when a process wishes
148: to apply a shared lock, read some information
149: and determine whether an update is required, then
150: apply an exclusive lock and update the file.
151: .PP
152: A request for a lock will cause a process to block if the lock
153: can not be immediately obtained.
154: In certain instances this is unsatisfactory.
155: For example, a process that
156: wants only to check if a lock is present would require a separate
157: mechanism to find out this information.
158: Consequently, a process may specify that its locking
159: request should return with an error if a lock can not be immediately
160: obtained.
161: Being able to conditionally request a lock
162: is useful to ``daemon'' processes
163: that wish to service a spooling area.
164: If the first instance of the
165: daemon locks the directory where spooling takes place,
166: later daemon processes can
167: easily check to see if an active daemon exists.
168: Since locks exist only while the locking processes exist,
169: lock files can never be left active after
170: the processes exit or if the system crashes.
171: .PP
172: Almost no deadlock detection is attempted.
173: The only deadlock detection done by the system is that the file
174: to which a lock is applied must not already have a
175: lock of the same type (i.e. the second of two successive calls
176: to apply a lock of the same type will fail).
177: .NH 2
178: Symbolic links
179: .PP
180: The traditional UNIX file system allows multiple
181: directory entries in the same file system
182: to reference a single file. Each directory entry
183: ``links'' a file's name to an inode and its contents.
184: The link concept is fundamental;
185: inodes do not reside in directories, but exist separately and
186: are referenced by links.
187: When all the links to an inode are removed,
188: the inode is deallocated.
189: This style of referencing an inode does
190: not allow references across physical file
191: systems, nor does it support inter-machine linkage.
192: To avoid these limitations
193: .I "symbolic links"
194: similar to the scheme used by Multics [Feiertag71] have been added.
195: .PP
196: A symbolic link is implemented as a file that contains a pathname.
197: When the system encounters a symbolic link while
198: interpreting a component of a pathname,
199: the contents of the symbolic link is prepended to the rest
200: of the pathname, and this name is interpreted to yield the
201: resulting pathname.
202: In UNIX, pathnames are specified relative to the root
203: of the file system hierarchy, or relative to a process's
204: current working directory. Pathnames specified relative
205: to the root are called absolute pathnames. Pathnames
206: specified relative to the current working directory are
207: termed relative pathnames.
208: If a symbolic link contains an absolute pathname,
209: the absolute pathname is used,
210: otherwise the contents of the symbolic link is evaluated
211: relative to the location of the link in the file hierarchy.
212: .PP
213: Normally programs do not want to be aware that there is a
214: symbolic link in a pathname that they are using.
215: However certain system utilities
216: must be able to detect and manipulate symbolic links.
217: Three new system calls provide the ability to detect, read, and write
218: symbolic links; seven system utilities required changes
219: to use these calls.
220: .PP
221: In future Berkeley software distributions
222: it may be possible to reference file systems located on
223: remote machines using pathnames. When this occurs,
224: it will be possible to create symbolic links that span machines.
225: .NH 2
226: Rename
227: .PP
228: Programs that create a new version of an existing
229: file typically create the
230: new version as a temporary file and then rename the temporary file
231: with the name of the target file.
232: In the old UNIX file system renaming required three calls to the system.
233: If a program were interrupted or the system crashed between these calls,
234: the target file could be left with only its temporary name.
235: To eliminate this possibility the \fIrename\fP system call
236: has been added. The rename call does the rename operation
237: in a fashion that guarantees the existence of the target name.
238: .PP
239: Rename works both on data files and directories.
240: When renaming directories,
241: the system must do special validation checks to insure
242: that the directory tree structure is not corrupted by the creation
243: of loops or inaccessible directories.
244: Such corruption would occur if a parent directory were moved
245: into one of its descendants.
246: The validation check requires tracing the descendents of the target
247: directory to insure that it does not include the directory being moved.
248: .NH 2
249: Quotas
250: .PP
251: The UNIX system has traditionally attempted to share all available
252: resources to the greatest extent possible.
253: Thus any single user can allocate all the available space
254: in the file system.
255: In certain environments this is unacceptable.
256: Consequently, a quota mechanism has been added for restricting the
257: amount of file system resources that a user can obtain.
258: The quota mechanism sets limits on both the number of inodes
259: and the number of disk blocks that a user may allocate.
260: A separate quota can be set for each user on each file system.
261: Resources are given both a hard and a soft limit.
262: When a program exceeds a soft limit,
263: a warning is printed on the users terminal;
264: the offending program is not terminated
265: unless it exceeds its hard limit.
266: The idea is that users should stay below their soft limit between
267: login sessions,
268: but they may use more resources while they are actively working.
269: To encourage this behavior,
270: users are warned when logging in if they are over
271: any of their soft limits.
272: If users fails to correct the problem for too many login sessions,
273: they are eventually reprimanded by having their soft limit
274: enforced as their hard limit.
275: .ds RH Acknowledgements
276: .sp 2
277: .ne 1i
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.