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