new copyright; att/bsd/shared
[unix-history] / usr / src / share / doc / smm / 05.fastfs / 5.t
index 132f8f5..502874a 100644 (file)
-.\" Copyright (c) 1980 Regents of the University of California.
-.\" All rights reserved.  The Berkeley software License Agreement
-.\" specifies the terms and conditions for redistribution.
+.\" Copyright (c) 1986 The Regents of the University of California.
+.\" All rights reserved.
 .\"
 .\"
-.\"    @(#)5.t 5.1 (Berkeley) %G%
+.\" %sccs.include.redist.roff%
+.\"
+.\"    @(#)5.t 6.3 (Berkeley) %G%
 .\"
 .ds RH Functional enhancements
 .NH 
 File system functional enhancements
 .PP
 .\"
 .ds RH Functional enhancements
 .NH 
 File system functional enhancements
 .PP
-The speed enhancements to the UNIX file system did not require
-any changes to the semantics or data structures viewed by the
-users.
-However several changes have been generally desired for some 
-time but have not been introduced because they would require users to 
+The performance enhancements to the
+UNIX file system did not require
+any changes to the semantics or
+data structures visible to application programs.
+However, several changes had been generally desired for some 
+time but had not been introduced because they would require users to 
 dump and restore all their file systems.
 Since the new file system already
 dump and restore all their file systems.
 Since the new file system already
-requires that all existing file systems
+required all existing file systems to
 be dumped and restored, 
 be dumped and restored, 
-these functional enhancements have been introduced at this time.
+these functional enhancements were introduced at this time.
 .NH 2
 Long file names
 .PP
 File names can now be of nearly arbitrary length.
 .NH 2
 Long file names
 .PP
 File names can now be of nearly arbitrary length.
-The only user programs affected by this change are
-those that access directories.
-To maintain portability among UNIX systems that
+Only programs that read directories are affected by this change.
+To promote portability to UNIX systems that
 are not running the new file system, a set of directory
 are not running the new file system, a set of directory
-access routines have been introduced that provide a uniform
+access routines have been introduced to provide a consistent
 interface to directories on both old and new systems.
 .PP
 interface to directories on both old and new systems.
 .PP
-Directories are allocated in units of 512 bytes.
+Directories are allocated in 512 byte units called chunks.
 This size is chosen so that each allocation can be transferred
 This size is chosen so that each allocation can be transferred
-to disk in a single atomic operation.
-Each allocation unit contains variable-length directory entries.
-Each entry is wholly contained in a single allocation unit.
-The first three fields of a directory entry are fixed and contain
-an inode number, the length of the entry, and the length
-of the name contained in the entry.
-Following this fixed size information is the null terminated name,
-padded to a 4 byte boundary.
-The maximum length of a name in a directory is currently 255 characters.
-.PP
-Free space in a directory is held by
-entries that have a record length that exceeds the space
-required by the directory entry itself.
-All the bytes in a directory unit are claimed by the directory entries.
-This normally results in the last entry in a directory being large.
-When entries are deleted from a directory,
-the space is returned to the previous entry in the same directory
-unit by increasing its length.
-If the first entry of a directory unit is free, then its 
-inode number is set to zero to show that it is unallocated.
+to disk in a single operation.
+Chunks are broken up into variable length records termed
+directory entries.  A directory entry
+contains the information necessary to map the name of a
+file to its associated inode.
+No directory entry is allowed to span multiple chunks.
+The first three fields of a directory entry are fixed length
+and contain: an inode number, the size of the entry, and the length
+of the file name contained in the entry.
+The remainder of an entry is variable length and contains
+a null terminated file name, padded to a 4 byte boundary.
+The maximum length of a file name in a directory is
+currently 255 characters.
+.PP
+Available space in a directory is recorded by having
+one or more entries accumulate the free space in their
+entry size fields.  This results in directory entries
+that are larger than required to hold the
+entry name plus fixed length fields.  Space allocated
+to a directory should always be completely accounted for
+by totaling up the sizes of its entries.
+When an entry is deleted from a directory,
+its space is returned to a previous entry
+in the same directory chunk by increasing the size of the
+previous entry by the size of the deleted entry.
+If the first entry of a directory chunk is free, then 
+the entry's inode number is set to zero to indicate
+that it is unallocated.
 .NH 2
 File locking
 .PP
 The old file system had no provision for locking files.
 Processes that needed to synchronize the updates of a
 .NH 2
 File locking
 .PP
 The old file system had no provision for locking files.
 Processes that needed to synchronize the updates of a
-file had to create a separate ``lock'' file to synchronize
-their updates.
+file had to use a separate ``lock'' file.
 A process would try to create a ``lock'' file. 
 A process would try to create a ``lock'' file. 
-If the creation succeeded, then it could proceed with its update;
-if the creation failed, then it would wait, and try again.
+If the creation succeeded, then the process
+could proceed with its update;
+if the creation failed, then the process would wait and try again.
 This mechanism had three drawbacks.
 This mechanism had three drawbacks.
-Processes consumed CPU time, by looping over attempts to create locks.
-Locks were left lying around following system crashes and had
-to be cleaned up by hand.
+Processes consumed CPU time by looping over attempts to create locks.
+Locks left lying around because of system crashes had
+to be manually removed (normally in a system startup command script).
 Finally, processes running as system administrator
 are always permitted to create files,
 Finally, processes running as system administrator
 are always permitted to create files,
-so they had to use a different mechanism.
+so were forced to use a different mechanism.
 While it is possible to get around all these problems,
 While it is possible to get around all these problems,
-the solutions are not straight-forward,
+the solutions are not straight forward,
 so a mechanism for locking files has been added.
 .PP
 so a mechanism for locking files has been added.
 .PP
-The most general schemes allow processes to concurrently update a file.
+The most general schemes allow multiple processes
+to concurrently update a file.
 Several of these techniques are discussed in [Peterson83].
 Several of these techniques are discussed in [Peterson83].
-A simpler technique is to simply serialize access with locks.
+A simpler technique is to serialize access to a file with locks.
 To attain reasonable efficiency,
 certain applications require the ability to lock pieces of a file.
 Locking down to the byte level has been implemented in the
 Onyx file system by [Bass81].
 To attain reasonable efficiency,
 certain applications require the ability to lock pieces of a file.
 Locking down to the byte level has been implemented in the
 Onyx file system by [Bass81].
-However, for the applications that currently run on the system,
+However, for the standard system applications,
 a mechanism that locks at the granularity of a file is sufficient.
 .PP
 Locking schemes fall into two classes,
 those using hard locks and those using advisory locks.
 The primary difference between advisory locks and hard locks is the
 a mechanism that locks at the granularity of a file is sufficient.
 .PP
 Locking schemes fall into two classes,
 those using hard locks and those using advisory locks.
 The primary difference between advisory locks and hard locks is the
-decision of when to override them. 
-A hard lock is always enforced whenever a program tries to
+extent of enforcement.
+A hard lock is always enforced when a program tries to
 access a file;
 an advisory lock is only applied when it is requested by a program.
 Thus advisory locks are only effective when all programs accessing
 a file use the locking scheme.
 access a file;
 an advisory lock is only applied when it is requested by a program.
 Thus advisory locks are only effective when all programs accessing
 a file use the locking scheme.
-With hard locks there must be some override policy implemented in the kernel,
-with advisory locks the policy is implemented by the user programs.
+With hard locks there must be some override
+policy implemented in the kernel.
+With advisory locks the policy is left to the user programs.
 In the UNIX system, programs with system administrator
 In the UNIX system, programs with system administrator
-privilege can override any protection scheme.
-Because many of the programs that need to use locks run as
-system administrators,
+privilege are allowed override any protection scheme.
+Because many of the programs that need to use locks must
+also run as the system administrator,
 we chose to implement advisory locks rather than 
 we chose to implement advisory locks rather than 
-create a protection scheme that was contrary to the UNIX 
-philosophy or could not be used by system administration
-programs.
+create an additional protection scheme that was inconsistent
+with the UNIX philosophy or could
+not be used by system administration programs.
 .PP
 The file locking facilities allow cooperating programs to apply
 advisory
 .PP
 The file locking facilities allow cooperating programs to apply
 advisory
@@ -108,29 +119,27 @@ advisory
 or
 .I exclusive
 locks on files.
 or
 .I exclusive
 locks on files.
-Only one process has an exclusive
+Only one process may have an exclusive
 lock on a file while multiple shared locks may be present.
 Both shared and exclusive locks cannot be present on
 a file at the same time.
 If any lock is requested when
 another process holds an exclusive lock,
 or an exclusive lock is requested when another process holds any lock,
 lock on a file while multiple shared locks may be present.
 Both shared and exclusive locks cannot be present on
 a file at the same time.
 If any lock is requested when
 another process holds an exclusive lock,
 or an exclusive lock is requested when another process holds any lock,
-the open will block until the lock can be gained.
+the lock request will block until the lock can be obtained.
 Because shared and exclusive locks are advisory only,
 even if a process has obtained a lock on a file,
 Because shared and exclusive locks are advisory only,
 even if a process has obtained a lock on a file,
-another process can override the lock by
-opening the same file without a lock.
+another process may access the file.
 .PP
 .PP
-Locks can be applied or removed on open files,
-so that locks can be manipulated without
-needing to close and reopen the file.
+Locks are applied or removed only on open files.
+This means that locks can be manipulated without
+needing to close and reopen a file.
 This is useful, for example, when a process wishes
 This is useful, for example, when a process wishes
-to open a file with a shared lock to read some information,
-to determine whether an update is required.
-It can then get an exclusive lock so that it can do a read,
-modify, and write to update the file in a consistent manner.
+to apply a shared lock, read some information
+and determine whether an update is required, then
+apply an exclusive lock and update the file.
 .PP
 .PP
-A request for a lock will cause the process to block if the lock
+A request for a lock will cause a process to block if the lock
 can not be immediately obtained.
 In certain instances this is unsatisfactory.
 For example, a process that
 can not be immediately obtained.
 In certain instances this is unsatisfactory.
 For example, a process that
@@ -139,40 +148,40 @@ mechanism to find out this information.
 Consequently, a process may specify that its locking
 request should return with an error if a lock can not be immediately
 obtained.
 Consequently, a process may specify that its locking
 request should return with an error if a lock can not be immediately
 obtained.
-Being able to poll for a lock is useful to ``daemon'' processes
+Being able to conditionally request a lock
+is useful to ``daemon'' processes
 that wish to service a spooling area.
 If the first instance of the
 daemon locks the directory where spooling takes place,
 later daemon processes can
 easily check to see if an active daemon exists.
 that wish to service a spooling area.
 If the first instance of the
 daemon locks the directory where spooling takes place,
 later daemon processes can
 easily check to see if an active daemon exists.
-Since the lock is removed when the process exits or the system crashes,
-there is no problem with unintentional locks files
-that must be cleared by hand.
+Since locks exist only while the locking processes exist,
+lock files can never be left active after
+the processes exit or if the system crashes.
 .PP
 Almost no deadlock detection is attempted.
 .PP
 Almost no deadlock detection is attempted.
-The only deadlock detection made by the system is that the file
-descriptor to which a lock is applied does not currently have a
+The only deadlock detection done by the system is that the file
+to which a lock is applied must not already have a
 lock of the same type (i.e. the second of two successive calls
 to apply a lock of the same type will fail).
 lock of the same type (i.e. the second of two successive calls
 to apply a lock of the same type will fail).
-Thus a  process can deadlock itself by
-requesting locks on two separate file descriptors for the same
-object.
 .NH 2
 Symbolic links
 .PP
 .NH 2
 Symbolic links
 .PP
-The 512 byte UNIX file system allows multiple
+The traditional UNIX file system allows multiple
 directory entries in the same file system
 directory entries in the same file system
-to reference a single file.
+to reference a single file.  Each directory entry
+``links'' a file's name to an inode and its contents.
 The link concept is fundamental;
 The link concept is fundamental;
-files do not live in directories, but exist separately and
+inodes do not reside in directories, but exist separately and
 are referenced by links.
 are referenced by links.
-When all the links are removed,
-the file is deallocated.
-This style of links does not allow references across physical file
+When all the links to an inode are removed,
+the inode is deallocated.
+This style of referencing an inode does
+not allow references across physical file
 systems, nor does it support inter-machine linkage. 
 To avoid these limitations
 .I "symbolic links"
 systems, nor does it support inter-machine linkage. 
 To avoid these limitations
 .I "symbolic links"
-have been added similar to the scheme used by Multics [Feiertag71].
+similar to the scheme used by Multics [Feiertag71] have been added.
 .PP
 A symbolic link is implemented as a file that contains a pathname.
 When the system encounters a symbolic link while
 .PP
 A symbolic link is implemented as a file that contains a pathname.
 When the system encounters a symbolic link while
@@ -180,7 +189,13 @@ interpreting a component of a pathname,
 the contents of the symbolic link is prepended to the rest
 of the pathname, and this name is interpreted to yield the
 resulting pathname.
 the contents of the symbolic link is prepended to the rest
 of the pathname, and this name is interpreted to yield the
 resulting pathname.
-If the symbolic link contains an absolute pathname,
+In UNIX, pathnames are specified relative to the root
+of the file system hierarchy, or relative to a process's
+current working directory.  Pathnames specified relative
+to the root are called absolute pathnames.  Pathnames
+specified relative to the current working directory are
+termed relative pathnames.
+If a symbolic link contains an absolute pathname,
 the absolute pathname is used,
 otherwise the contents of the symbolic link is evaluated
 relative to the location of the link in the file hierarchy.
 the absolute pathname is used,
 otherwise the contents of the symbolic link is evaluated
 relative to the location of the link in the file hierarchy.
@@ -190,35 +205,35 @@ symbolic link in a pathname that they are using.
 However certain system utilities
 must be able to detect and manipulate symbolic links.
 Three new system calls provide the ability to detect, read, and write
 However certain system utilities
 must be able to detect and manipulate symbolic links.
 Three new system calls provide the ability to detect, read, and write
-symbolic links, and seven system utilities were modified to use these calls.
+symbolic links; seven system utilities required changes
+to use these calls.
 .PP
 .PP
-In future Berkeley software distributions 
-it will be possible to mount file systems from other
-machines within a local file system.
-When this occurs,
+In future Berkeley software distributions
+it may be possible to reference file systems located on
+remote machines using pathnames.  When this occurs,
 it will be possible to create symbolic links that span machines.
 .NH 2
 Rename
 .PP
 it will be possible to create symbolic links that span machines.
 .NH 2
 Rename
 .PP
-Programs that create new versions of data files typically create the
+Programs that create a new version of an existing
+file typically create the
 new version as a temporary file and then rename the temporary file
 new version as a temporary file and then rename the temporary file
-with the original name of the data file.
-In the old UNIX file systems the renaming required three calls to the system.
-If the program were interrupted or the system crashed between
-these calls,
-the data file could be left with only its temporary name.
-To eliminate this possibility a single system call
-has been added that performs the rename in an
-atomic fashion to guarantee the existence of the original name.
-.PP
-In addition, the rename facility allows directories to be moved around
-in the directory tree hierarchy.
-The rename system call performs special validation checks to insure
+with the name of the target file.
+In the old UNIX file system renaming required three calls to the system.
+If a program were interrupted or the system crashed between these calls,
+the target file could be left with only its temporary name.
+To eliminate this possibility the \fIrename\fP system call
+has been added.  The rename call does the rename operation
+in a fashion that guarantees the existence of the target name.
+.PP
+Rename works both on data files and directories.
+When renaming directories,
+the system must do special validation checks to insure
 that the directory tree structure is not corrupted by the creation
 of loops or inaccessible directories.
 Such corruption would occur if a parent directory were moved
 into one of its descendants.
 that the directory tree structure is not corrupted by the creation
 of loops or inaccessible directories.
 Such corruption would occur if a parent directory were moved
 into one of its descendants.
-The validation check requires tracing the ancestry of the target
+The validation check requires tracing the descendents of the target
 directory to insure that it does not include the directory being moved.
 .NH 2
 Quotas
 directory to insure that it does not include the directory being moved.
 .NH 2
 Quotas
@@ -230,22 +245,23 @@ in the file system.
 In certain environments this is unacceptable.
 Consequently, a quota mechanism has been added for restricting the
 amount of file system resources that a user can obtain.
 In certain environments this is unacceptable.
 Consequently, a quota mechanism has been added for restricting the
 amount of file system resources that a user can obtain.
-The quota mechanism sets limits on both the number of files
+The quota mechanism sets limits on both the number of inodes
 and the number of disk blocks that a user may allocate.
 A separate quota can be set for each user on each file system.
 and the number of disk blocks that a user may allocate.
 A separate quota can be set for each user on each file system.
-Each resource is given both a hard and a soft limit.
+Resources are given both a hard and a soft limit.
 When a program exceeds a soft limit,
 a warning is printed on the users terminal;
 the offending program is not terminated
 unless it exceeds its hard limit.
 The idea is that users should stay below their soft limit between
 login sessions,
 When a program exceeds a soft limit,
 a warning is printed on the users terminal;
 the offending program is not terminated
 unless it exceeds its hard limit.
 The idea is that users should stay below their soft limit between
 login sessions,
-but they may use more space while they are actively working.
+but they may use more resources while they are actively working.
 To encourage this behavior,
 users are warned when logging in if they are over
 any of their soft limits.
 To encourage this behavior,
 users are warned when logging in if they are over
 any of their soft limits.
-If they fail to correct the problem for too many login sessions,
+If users fails to correct the problem for too many login sessions,
 they are eventually reprimanded by having their soft limit
 enforced as their hard limit.
 they are eventually reprimanded by having their soft limit
 enforced as their hard limit.
-.ds RH Software engineering
-.bp
+.ds RH Acknowledgements
+.sp 2
+.ne 1i