Commit | Line | Data |
---|---|---|
9299c540 KB |
1 | .\" Copyright (c) 1986 The Regents of the University of California. |
2 | .\" All rights reserved. | |
bade79af | 3 | .\" |
9299c540 KB |
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) %G% | |
bade79af KD |
17 | .\" |
18 | .ds RH Functional enhancements | |
19 | .NH | |
20 | File system functional enhancements | |
21 | .PP | |
c20eb73f KD |
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 | |
bade79af KD |
28 | dump and restore all their file systems. |
29 | Since the new file system already | |
c20eb73f | 30 | required all existing file systems to |
bade79af | 31 | be dumped and restored, |
c20eb73f | 32 | these functional enhancements were introduced at this time. |
bade79af KD |
33 | .NH 2 |
34 | Long file names | |
35 | .PP | |
36 | File names can now be of nearly arbitrary length. | |
c20eb73f KD |
37 | Only programs that read directories are affected by this change. |
38 | To promote portability to UNIX systems that | |
bade79af | 39 | are not running the new file system, a set of directory |
c20eb73f | 40 | access routines have been introduced to provide a consistent |
bade79af KD |
41 | interface to directories on both old and new systems. |
42 | .PP | |
c20eb73f | 43 | Directories are allocated in 512 byte units called chunks. |
bade79af | 44 | This size is chosen so that each allocation can be transferred |
c20eb73f KD |
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. | |
bade79af KD |
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 | |
c20eb73f | 78 | file had to use a separate ``lock'' file. |
bade79af | 79 | A process would try to create a ``lock'' file. |
c20eb73f KD |
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. | |
bade79af | 83 | This mechanism had three drawbacks. |
c20eb73f KD |
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). | |
bade79af KD |
87 | Finally, processes running as system administrator |
88 | are always permitted to create files, | |
c20eb73f | 89 | so were forced to use a different mechanism. |
bade79af | 90 | While it is possible to get around all these problems, |
c20eb73f | 91 | the solutions are not straight forward, |
bade79af KD |
92 | so a mechanism for locking files has been added. |
93 | .PP | |
c20eb73f KD |
94 | The most general schemes allow multiple processes |
95 | to concurrently update a file. | |
bade79af | 96 | Several of these techniques are discussed in [Peterson83]. |
c20eb73f | 97 | A simpler technique is to serialize access to a file with locks. |
bade79af KD |
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]. | |
c20eb73f | 102 | However, for the standard system applications, |
bade79af KD |
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 | |
c20eb73f KD |
108 | extent of enforcement. |
109 | A hard lock is always enforced when a program tries to | |
bade79af KD |
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. | |
c20eb73f KD |
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. | |
bade79af | 117 | In the UNIX system, programs with system administrator |
c20eb73f KD |
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, | |
bade79af | 121 | we chose to implement advisory locks rather than |
c20eb73f KD |
122 | create an additional protection scheme that was inconsistent |
123 | with the UNIX philosophy or could | |
124 | not be used by system administration programs. | |
bade79af KD |
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. | |
c20eb73f | 132 | Only one process may have an exclusive |
bade79af KD |
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, | |
c20eb73f | 139 | the lock request will block until the lock can be obtained. |
bade79af KD |
140 | Because shared and exclusive locks are advisory only, |
141 | even if a process has obtained a lock on a file, | |
c20eb73f | 142 | another process may access the file. |
bade79af | 143 | .PP |
c20eb73f KD |
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. | |
bade79af | 147 | This is useful, for example, when a process wishes |
c20eb73f KD |
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. | |
bade79af | 151 | .PP |
c20eb73f | 152 | A request for a lock will cause a process to block if the lock |
bade79af KD |
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. | |
c20eb73f KD |
161 | Being able to conditionally request a lock |
162 | is useful to ``daemon'' processes | |
bade79af KD |
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. | |
c20eb73f KD |
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. | |
bade79af KD |
171 | .PP |
172 | Almost no deadlock detection is attempted. | |
c20eb73f KD |
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 | |
bade79af KD |
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). | |
bade79af KD |
177 | .NH 2 |
178 | Symbolic links | |
179 | .PP | |
c20eb73f | 180 | The traditional UNIX file system allows multiple |
bade79af | 181 | directory entries in the same file system |
c20eb73f KD |
182 | to reference a single file. Each directory entry |
183 | ``links'' a file's name to an inode and its contents. | |
bade79af | 184 | The link concept is fundamental; |
c20eb73f | 185 | inodes do not reside in directories, but exist separately and |
bade79af | 186 | are referenced by links. |
c20eb73f KD |
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 | |
bade79af KD |
191 | systems, nor does it support inter-machine linkage. |
192 | To avoid these limitations | |
193 | .I "symbolic links" | |
c20eb73f | 194 | similar to the scheme used by Multics [Feiertag71] have been added. |
bade79af KD |
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. | |
c20eb73f KD |
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, | |
bade79af KD |
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 | |
c20eb73f KD |
218 | symbolic links; seven system utilities required changes |
219 | to use these calls. | |
bade79af | 220 | .PP |
c20eb73f KD |
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, | |
bade79af KD |
224 | it will be possible to create symbolic links that span machines. |
225 | .NH 2 | |
226 | Rename | |
227 | .PP | |
c20eb73f KD |
228 | Programs that create a new version of an existing |
229 | file typically create the | |
bade79af | 230 | new version as a temporary file and then rename the temporary file |
c20eb73f KD |
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 | |
bade79af KD |
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. | |
c20eb73f | 246 | The validation check requires tracing the descendents of the target |
bade79af KD |
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. | |
c20eb73f | 258 | The quota mechanism sets limits on both the number of inodes |
bade79af KD |
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. | |
c20eb73f | 261 | Resources are given both a hard and a soft limit. |
bade79af KD |
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, | |
c20eb73f | 268 | but they may use more resources while they are actively working. |
bade79af KD |
269 | To encourage this behavior, |
270 | users are warned when logging in if they are over | |
271 | any of their soft limits. | |
c20eb73f | 272 | If users fails to correct the problem for too many login sessions, |
bade79af KD |
273 | they are eventually reprimanded by having their soft limit |
274 | enforced as their hard limit. | |
c20eb73f KD |
275 | .ds RH Acknowledgements |
276 | .sp 2 | |
277 | .ne 1i |