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