Return to 5.t CVS log

Up to [CSRG BSD Unix] / 43BSDReno / share / doc / smm / 14.fastfs

Annotation of 43BSDReno/share/doc/smm/14.fastfs/5.t, revision 1.1

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.