diff options
| -rw-r--r-- | share/doc/Makefile | 12 | ||||
| -rw-r--r-- | share/doc/README | 51 | ||||
| -rw-r--r-- | share/doc/psd/00.contents | 193 | ||||
| -rw-r--r-- | share/doc/psd/Makefile | 20 | ||||
| -rw-r--r-- | share/doc/psd/Title | 128 | ||||
| -rw-r--r-- | share/doc/smm/05.fastfs/0.t | 157 | ||||
| -rw-r--r-- | share/doc/smm/05.fastfs/1.t | 110 | ||||
| -rw-r--r-- | share/doc/smm/05.fastfs/2.t | 141 | ||||
| -rw-r--r-- | share/doc/smm/05.fastfs/3.t | 592 | ||||
| -rw-r--r-- | share/doc/smm/05.fastfs/4.t | 250 | ||||
| -rw-r--r-- | share/doc/smm/05.fastfs/5.t | 291 | ||||
| -rw-r--r-- | share/doc/smm/05.fastfs/6.t | 157 | ||||
| -rw-r--r-- | share/doc/smm/05.fastfs/Makefile | 14 | ||||
| -rw-r--r-- | share/doc/smm/Makefile | 11 | ||||
| -rw-r--r-- | share/doc/usd/Makefile | 10 |
15 files changed, 0 insertions, 2137 deletions
diff --git a/share/doc/Makefile b/share/doc/Makefile deleted file mode 100644 index 0e0bb4a3746..00000000000 --- a/share/doc/Makefile +++ /dev/null @@ -1,12 +0,0 @@ -# $OpenBSD: Makefile,v 1.4 2010/01/04 17:50:39 deraadt Exp $ -# @(#)Makefile 8.1 (Berkeley) 6/5/93 - -FILES= README - -all depend includes lint tags: - -realinstall: - install -c -o ${DOCOWN} -g ${DOCGRP} -m ${DOCMODE} ${FILES} \ - ${DESTDIR}${DOCDIR} - -.include <bsd.subdir.mk> diff --git a/share/doc/README b/share/doc/README deleted file mode 100644 index 96458e9a4ac..00000000000 --- a/share/doc/README +++ /dev/null @@ -1,51 +0,0 @@ -# $OpenBSD: README,v 1.5 2008/06/07 01:59:36 jdixon Exp $ -# -# Copyright (c) 2004 Jason McIntyre <jmc@openbsd.org> -# -# Permission to use, copy, modify, and distribute this software for any -# purpose with or without fee is hereby granted, provided that the above -# copyright notice and this permission notice appear in all copies. -# -# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES -# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF -# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR -# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES -# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN -# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF -# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. -# - -The documents in this directory consist of various, miscellaneous, system docs: - - html/ HTML documents for bind, curses, httpd, lynx, and milter - psd/ UNIX Programmer's Supplementary Documents - smm/ UNIX System Manager's Manuals - usd/ UNIX User's Supplementary Documents - -The documentation in the psd, smm, and usd subdirectories are roff source, -and can be used to generate documents in any of the formats available to the -groff(1) document formatting system. - -Within any given subdirectory, simply typing: - - # make - -will generate a pre-formatted document in PostScript format, called `paper.ps'. -The document can be viewed with the help of a PostScript viewer, such as -`ghostview' or `gv', and the PostScript back-end `ghostscript'. See ports(7) -and packages(7) for further information on how to install this software. - -ASCII text format documents, suitable for viewing with a pager such as -less(1), can be generated by typing: - - # make paper.txt - -However, the PostScript output is much prettier :) - -The documentation in the html subdirectory can by viewed using any HTML-capable -browser such as lynx(1). - -Note: Some of the subdirectories are empty, for a variety of reasons: -the papers are simply out of date; the papers refer to applications no -longer installed on the system; licensing issues; the papers have been -superseded by GNU info(1) files, etc. diff --git a/share/doc/psd/00.contents b/share/doc/psd/00.contents deleted file mode 100644 index 894aa9fb5c4..00000000000 --- a/share/doc/psd/00.contents +++ /dev/null @@ -1,193 +0,0 @@ -.\" $OpenBSD: 00.contents,v 1.4 2004/04/09 12:10:03 jmc Exp $ -.\" -.\" Copyright (c) 1986, 1993 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" -.\" @(#)00.contents 8.1 (Berkeley) 6/8/93 -.\" -.if n \{\ -.po 5n -.ll 70n -.\} -.OH '''PSD Contents' -.EH 'PSD Contents''' -.TL -UNIX Programmer's Supplementary Documents (PSD) -.sp -\s-24.4 Berkeley Software Distribution\s+2 -.sp -\fRJune, 1993\fR -.PP -This volume contains documents which supplement the manual pages in -.I -The -.UX -Programmer's Reference Manual -.R -for the 4.4BSD system as distributed by U.C. Berkeley. -.SH -Documents of Historical Interest -.IP -.tl 'The Unix Time\-Sharing System''PSD:1' -.QP -Dennis Ritchie and Ken Thompson's original paper about UNIX, reprinted -from Communications of the ACM. - -.IP -.tl 'Unix Implementation''PSD:2' -.QP -Ken Thompson's description of the implementation of the Version 7 -kernel and file system. - -.IP -.tl 'The Unix I/O System''PSD:3' -.QP -Dennis Ritchie's overview of the I/O System of Version 7; still helpful for -those writing device drivers. - -.IP -.tl 'Unix Programming \- Second Edition ''PSD:4' -.QP -Describes the programming interface to the UNIX version 7 operating -system and the standard I/O library. Should be supplemented by -Kernighan and Pike, ``The UNIX Programming Environment'', -Prentice-Hall, 1984 and especially by the Programmer Reference Manual -section 2 (system calls) and 3 (library routines). - -.IP -.tl 'Berkeley Software Architecture Manual (4.4 Edition)''PSD:5' -.QP -A concise and terse description of the system call interface -provided in Berkeley Unix, as revised for 4.4BSD. -This will never be a best seller. - -.SH -Languages in common use -.IP -.tl 'The C Programming Language \- Reference Manual''PSD:6' -.QP -Official statement of the syntax of C. -Should be supplemented by ``The C Programming Language,'' -B.W. Kernighan and D.M. Ritchie, Prentice-Hall, 1978, that -contains a tutorial introduction and many examples. - -.IP -.tl 'Berkeley Pascal User\'s Manual''PSD:7' -.QP -An implementation of this language popular for learning to program. - -.IP -.tl 'A Portable Fortran 77 Compiler''PSD:8' -.QP -A revised version of the document which originally appeared in -Volume 2b of the Bell Labs documentation; -this version reflects the work done at Berkeley. - -.IP -.tl 'Introduction to the f77 I/O Library''PSD:9' -.QP -A description of the revised input/output library for Fortran 77, -reflecting work carried out at Berkeley. - -.SH -Programming Tools -.IP -.tl 'Debugging with GDB: The GNU Source-Level Debugger''PSD:10' -.QP -How to debug programs using the source level \fIgdb\fP debugger -(or how to debug programs without having to know much about machine language). - -.IP -.tl 'A Tutorial Introduction to ADB''PSD:11' -.QP -How to debug programs using the assembly-language level \fIadb\fP debugger. - -.IP -.tl 'Make \- A Program for Maintaining Computer Programs''PSD:12' -.QP -Indispensable tool for making sure large programs are properly -compiled with minimal effort. - -.IP -.tl 'An Introduction to the Revision Control System''PSD:13' -.QP -RCS is a user-contributed tool for working together with other people -without stepping on each other's toes. -An alternative to \fIsccs\fR for controlling software changes. - -.IP -.tl 'An Introduction to the Source Code Control System''PSD:14' -.QP -A useful introductory article for those users with -installations licensed for SCCS. - -.IP -.tl 'YACC: Yet Another Compiler-Compiler''PSD:15' -.QP -Converts a BNF specification of a language and semantic actions -written in C into a compiler for that language. - -.IP -.tl 'LEX \- A Lexical Analyzer Generator''PSD:16' -.QP -Creates a recognizer for a set of regular expressions: -each regular expression can be followed by arbitrary C code -to be executed upon finding the regular expression. - -.IP -.tl 'The M4 Macro Processor''PSD:17' -.QP -M4 is a macro processor useful in its own right and as a -front-end for C, Ratfor, and Cobol. - -.IP -.tl 'gprof: a Call Graph Execution Profiler''PSD:18' -.QP -A program to show the call graph and execution time of a program. -Indispensable aid for improving the running time of almost everything. - -.SH -Programming Libraries -.IP -.tl 'Screen Updating and Cursor Movement Optimization''PSD:19' -.QP -Describes the \fIcurses\fP package, an aid for writing screen-oriented, -terminal-independent programs. - -.SH -General Reference -.IP -.tl 'An Introductory 4.4BSD Interprocess Communication Tutorial''PSD:20' -.QP -How to write programs that use the Interprocess Communication Facilities -of 4.4BSD. - -.IP -.tl 'An Advanced 4.4BSD Interprocess Communication Tutorial''PSD:21' -.QP -The reference document (with some examples) for the Interprocess Communication -Facilities of 4.4BSD. diff --git a/share/doc/psd/Makefile b/share/doc/psd/Makefile deleted file mode 100644 index 33643dd0b4d..00000000000 --- a/share/doc/psd/Makefile +++ /dev/null @@ -1,20 +0,0 @@ -# $OpenBSD: Makefile,v 1.8 2010/07/01 20:04:10 tedu Exp $ - -DOCDIR= /usr/share/doc/psd -FILES= Makefile -SUBDIR= -.if exists(12.make) -SUBDIR+= 12.make -.endif -.if exists(18.gprof) -SUBDIR+= 18.gprof -.endif -.if exists(19.curses) -SUBDIR+= 19.curses -.endif - -beforeinstall: - install -c -o ${DOCOWN} -g ${DOCGRP} -m ${DOCMODE} ${FILES} \ - ${DESTDIR}${DOCDIR} - -.include <bsd.subdir.mk> diff --git a/share/doc/psd/Title b/share/doc/psd/Title deleted file mode 100644 index de0c6930ac7..00000000000 --- a/share/doc/psd/Title +++ /dev/null @@ -1,128 +0,0 @@ -.\" $OpenBSD: Title,v 1.5 2004/04/09 12:10:04 jmc Exp $ -.\" -.\" Copyright (c) 1986, 1993 The Regents of the University of California. -.\" All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" -.\" @(#)Title 8.2 (Berkeley) 4/19/94 -.\" -.if n \{\ -.po 5n -.ll 70n -.\} -.ps 18 -.vs 22 -.sp 2.75i -.ft B -.ce 3 -UNIX Programmer's Supplementary Documents -(PSD) -.ps 14 -.vs 16 -.sp |4i -.ce 2 -4.4 Berkeley Software Distribution -.sp |5.75i -.ft R -.pt 12 -.vs 16 -.ce -June, 1993 -.sp |8.2i -.ce 5 -Computer Systems Research Group -Computer Science Division -Department of Electrical Engineering and Computer Science -University of California -Berkeley, California 94720 -.bp -\& -.sp |1i -.hy 0 -.ps 10 -.vs 12p -Copyright 1979, 1980, 1983, 1986, 1993 -The Regents of the University of California. All rights reserved. -.sp 2 -Other than the specific documents listed below as copyrighted by AT&T, -redistribution and use of this manual in source and binary forms, -with or without modification, are permitted provided that the -following conditions are met: -.sp 0.5 -.in +0.2i -.ta 0.2i -.ti -0.2i -1) Redistributions of this manual must retain the copyright -notices on this page, this list of conditions and the following disclaimer. -.ti -0.2i -2) Software or documentation that incorporates part of this manual must -reproduce the copyright notices on this page, this list of conditions and -the following disclaimer in the documentation and/or other materials -provided with the distribution. -.ti -0.2i -3) Neither the name of the University nor the names of its contributors -may be used to endorse or promote products derived from this software -without specific prior written permission. -.in -0.2i -.sp -\fB\s-1THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -SUCH DAMAGE.\s+1\fP -.sp 2 -Documents PSD:1, 2, 3, 4, 6, 11, 15, 16, and 17 -are copyright 1979, AT&T Bell Laboratories, Incorporated. -Document PSD:8 is a modification of an earlier document that -is copyrighted 1979 by AT&T Bell Laboratories, Incorporated. -Holders of \x'-1p'UNIX\v'-4p'\s-3TM\s0\v'4p'/32V, -System III, or System V software licenses are -permitted to copy these documents, or any portion of them, -as necessary for licensed use of the software, -provided this copyright notice and statement of permission -are included. -.sp 2 -Document PSD:10 is part of the user contributed software and is -copyright 1992 by the Free Software Foundation, Inc. -Permission is granted to make and distribute verbatim copies of -this document provided the copyright notice and this permission notice -are preserved on all copies. -.sp 2 -Document PSD:13 is part of the user contributed software and is -copyright 1983 by Walter F. Tichy. -Permission to copy the RCS documentation or any portion thereof as -necessary for licensed use of the software is granted to licensees -of this software, provided this copyright notice is included. -.sp 2 -The views and conclusions contained in this manual are those of the -authors and should not be interpreted as representing official policies, -either expressed or implied, of the Regents of the University of California. diff --git a/share/doc/smm/05.fastfs/0.t b/share/doc/smm/05.fastfs/0.t deleted file mode 100644 index fd76c9cec67..00000000000 --- a/share/doc/smm/05.fastfs/0.t +++ /dev/null @@ -1,157 +0,0 @@ -.\" $OpenBSD: 0.t,v 1.3 2003/06/02 23:30:11 millert Exp $ -.\" -.\" Copyright (c) 1986, 1993 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" -.\" @(#)0.t 8.1 (Berkeley) 6/8/93 -.\" -.EQ -delim $$ -.EN -.if n .ND -.TL -A Fast File System for UNIX* -.EH 'SMM:05-%''A Fast File System for \s-2UNIX\s+2' -.OH 'A Fast File System for \s-2UNIX\s+2''SMM:05-%' -.AU -Marshall Kirk McKusick, William N. Joy\(dg, -Samuel J. Leffler\(dd, Robert S. Fabry -.AI -Computer Systems Research Group -Computer Science Division -Department of Electrical Engineering and Computer Science -University of California, Berkeley -Berkeley, CA 94720 -.AB -.FS -* UNIX is a trademark of Bell Laboratories. -.FE -.FS -\(dg William N. Joy is currently employed by: -Sun Microsystems, Inc, 2550 Garcia Avenue, Mountain View, CA 94043 -.FE -.FS -\(dd Samuel J. Leffler is currently employed by: -Lucasfilm Ltd., PO Box 2009, San Rafael, CA 94912 -.FE -.FS -This work was done under grants from -the National Science Foundation under grant MCS80-05144, -and the Defense Advance Research Projects Agency (DoD) under -ARPA Order No. 4031 monitored by Naval Electronic System Command under -Contract No. N00039-82-C-0235. -.FE -A reimplementation of the UNIX file system is described. -The reimplementation provides substantially higher throughput -rates by using more flexible allocation policies -that allow better locality of reference and can -be adapted to a wide range of peripheral and processor characteristics. -The new file system clusters data that is sequentially accessed -and provides two block sizes to allow fast access to large files -while not wasting large amounts of space for small files. -File access rates of up to ten times faster than the traditional -UNIX file system are experienced. -Long needed enhancements to the programmers' -interface are discussed. -These include a mechanism to place advisory locks on files, -extensions of the name space across file systems, -the ability to use long file names, -and provisions for administrative control of resource usage. -.sp -.LP -Revised February 18, 1984 -.AE -.LP -.sp 2 -CR Categories and Subject Descriptors: -D.4.3 -.B "[Operating Systems]": -File Systems Management \- -.I "file organization, directory structures, access methods"; -D.4.2 -.B "[Operating Systems]": -Storage Management \- -.I "allocation/deallocation strategies, secondary storage devices"; -D.4.8 -.B "[Operating Systems]": -Performance \- -.I "measurements, operational analysis"; -H.3.2 -.B "[Information Systems]": -Information Storage \- -.I "file organization" -.sp -Additional Keywords and Phrases: -UNIX, -file system organization, -file system performance, -file system design, -application program interface. -.sp -General Terms: -file system, -measurement, -performance. -.bp -.ce -.B "TABLE OF CONTENTS" -.LP -.sp 1 -.nf -.B "1. Introduction" -.LP -.sp .5v -.nf -.B "2. Old file system -.LP -.sp .5v -.nf -.B "3. New file system organization -3.1. Optimizing storage utilization -3.2. File system parameterization -3.3. Layout policies -.LP -.sp .5v -.nf -.B "4. Performance -.LP -.sp .5v -.nf -.B "5. File system functional enhancements -5.1. Long file names -5.2. File locking -5.3. Symbolic links -5.4. Rename -5.5. Quotas -.LP -.sp .5v -.nf -.B Acknowledgements -.LP -.sp .5v -.nf -.B References diff --git a/share/doc/smm/05.fastfs/1.t b/share/doc/smm/05.fastfs/1.t deleted file mode 100644 index e2aec2f1a0a..00000000000 --- a/share/doc/smm/05.fastfs/1.t +++ /dev/null @@ -1,110 +0,0 @@ -.\" $OpenBSD: 1.t,v 1.3 2003/06/02 23:30:11 millert Exp $ -.\" -.\" Copyright (c) 1986, 1993 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" -.\" @(#)1.t 8.1 (Berkeley) 6/8/93 -.\" -.ds RH Introduction -.NH -Introduction -.PP -This paper describes the changes from the original 512 byte UNIX file -system to the new one released with the 4.2 Berkeley Software Distribution. -It presents the motivations for the changes, -the methods used to effect these changes, -the rationale behind the design decisions, -and a description of the new implementation. -This discussion is followed by a summary of -the results that have been obtained, -directions for future work, -and the additions and changes -that have been made to the facilities that are -available to programmers. -.PP -The original UNIX system that runs on the PDP-11\(dg -.FS -\(dg DEC, PDP, VAX, MASSBUS, and UNIBUS are -trademarks of Digital Equipment Corporation. -.FE -has simple and elegant file system facilities. File system input/output -is buffered by the kernel; -there are no alignment constraints on -data transfers and all operations are made to appear synchronous. -All transfers to the disk are in 512 byte blocks, which can be placed -arbitrarily within the data area of the file system. Virtually -no constraints other than available disk space are placed on file growth -[Ritchie74], [Thompson78].* -.FS -* In practice, a file's size is constrained to be less than about -one gigabyte. -.FE -.PP -When used on the VAX-11 together with other UNIX enhancements, -the original 512 byte UNIX file -system is incapable of providing the data throughput rates -that many applications require. -For example, -applications -such as VLSI design and image processing -do a small amount of processing -on a large quantities of data and -need to have a high throughput from the file system. -High throughput rates are also needed by programs -that map files from the file system into large virtual -address spaces. -Paging data in and out of the file system is likely -to occur frequently [Ferrin82b]. -This requires a file system providing -higher bandwidth than the original 512 byte UNIX -one that provides only about -two percent of the maximum disk bandwidth or about -20 kilobytes per second per arm [White80], [Smith81b]. -.PP -Modifications have been made to the UNIX file system to improve -its performance. -Since the UNIX file system interface -is well understood and not inherently slow, -this development retained the abstraction and simply changed -the underlying implementation to increase its throughput. -Consequently, users of the system have not been faced with -massive software conversion. -.PP -Problems with file system performance have been dealt with -extensively in the literature; see [Smith81a] for a survey. -Previous work to improve the UNIX file system performance has been -done by [Ferrin82a]. -The UNIX operating system drew many of its ideas from Multics, -a large, high performance operating system [Feiertag71]. -Other work includes Hydra [Almes78], -Spice [Thompson80], -and a file system for a LISP environment [Symbolics81]. -A good introduction to the physical latencies of disks is -described in [Pechura83]. -.ds RH Old file system -.sp 2 -.ne 1i diff --git a/share/doc/smm/05.fastfs/2.t b/share/doc/smm/05.fastfs/2.t deleted file mode 100644 index eba339b9372..00000000000 --- a/share/doc/smm/05.fastfs/2.t +++ /dev/null @@ -1,141 +0,0 @@ -.\" $OpenBSD: 2.t,v 1.3 2003/06/02 23:30:11 millert Exp $ -.\" -.\" Copyright (c) 1986, 1993 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" -.\" @(#)2.t 8.1 (Berkeley) 6/8/93 -.\" -.ds RH Old file system -.NH -Old File System -.PP -In the file system developed at Bell Laboratories -(the ``traditional'' file system), -each disk drive is divided into one or more -partitions. Each of these disk partitions may contain -one file system. A file system never spans multiple -partitions.\(dg -.FS -\(dg By ``partition'' here we refer to the subdivision of -physical space on a disk drive. In the traditional file -system, as in the new file system, file systems are really -located in logical disk partitions that may overlap. This -overlapping is made available, for example, -to allow programs to copy entire disk drives containing multiple -file systems. -.FE -A file system is described by its super-block, -which contains the basic parameters of the file system. -These include the number of data blocks in the file system, -a count of the maximum number of files, -and a pointer to the \fIfree list\fP, a linked -list of all the free blocks in the file system. -.PP -Within the file system are files. -Certain files are distinguished as directories and contain -pointers to files that may themselves be directories. -Every file has a descriptor associated with it called an -.I "inode". -An inode contains information describing ownership of the file, -time stamps marking last modification and access times for the file, -and an array of indices that point to the data blocks for the file. -For the purposes of this section, we assume that the first 8 blocks -of the file are directly referenced by values stored -in an inode itself*. -.FS -* The actual number may vary from system to system, but is usually in -the range 5-13. -.FE -An inode may also contain references to indirect blocks -containing further data block indices. -In a file system with a 512 byte block size, a singly indirect -block contains 128 further block addresses, -a doubly indirect block contains 128 addresses of further singly indirect -blocks, -and a triply indirect block contains 128 addresses of further doubly indirect -blocks. -.PP -A 150 megabyte traditional UNIX file system consists -of 4 megabytes of inodes followed by 146 megabytes of data. -This organization segregates the inode information from the data; -thus accessing a file normally incurs a long seek from the -file's inode to its data. -Files in a single directory are not typically allocated -consecutive slots in the 4 megabytes of inodes, -causing many non-consecutive blocks of inodes -to be accessed when executing -operations on the inodes of several files in a directory. -.PP -The allocation of data blocks to files is also suboptimum. -The traditional -file system never transfers more than 512 bytes per disk transaction -and often finds that the next sequential data block is not on the same -cylinder, forcing seeks between 512 byte transfers. -The combination of the small block size, -limited read-ahead in the system, -and many seeks severely limits file system throughput. -.PP -The first work at Berkeley on the UNIX file system attempted to improve both -reliability and throughput. -The reliability was improved by staging modifications -to critical file system information so that they could -either be completed or repaired cleanly by a program -after a crash [Kowalski78]. -The file system performance was improved by a factor of more than two by -changing the basic block size from 512 to 1024 bytes. -The increase was because of two factors: -each disk transfer accessed twice as much data, -and most files could be described without need to access -indirect blocks since the direct blocks contained twice as much data. -The file system with these changes will henceforth be referred to as the -.I "old file system." -.PP -This performance improvement gave a strong indication that -increasing the block size was a good method for improving -throughput. -Although the throughput had doubled, -the old file system was still using only about -four percent of the disk bandwidth. -The main problem was that although the free list was initially -ordered for optimal access, -it quickly became scrambled as files were created and removed. -Eventually the free list became entirely random, -causing files to have their blocks allocated randomly over the disk. -This forced a seek before every block access. -Although old file systems provided transfer rates of up -to 175 kilobytes per second when they were first created, -this rate deteriorated to 30 kilobytes per second after a -few weeks of moderate use because of this -randomization of data block placement. -There was no way of restoring the performance of an old file system -except to dump, rebuild, and restore the file system. -Another possibility, as suggested by [Maruyama76], -would be to have a process that periodically -reorganized the data on the disk to restore locality. -.ds RH New file system -.sp 2 -.ne 1i diff --git a/share/doc/smm/05.fastfs/3.t b/share/doc/smm/05.fastfs/3.t deleted file mode 100644 index 813b0e6f6ce..00000000000 --- a/share/doc/smm/05.fastfs/3.t +++ /dev/null @@ -1,592 +0,0 @@ -.\" $OpenBSD: 3.t,v 1.3 2003/06/02 23:30:11 millert Exp $ -.\" -.\" Copyright (c) 1986, 1993 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" -.\" @(#)3.t 8.1 (Berkeley) 6/8/93 -.\" -.ds RH New file system -.NH -New file system organization -.PP -In the new file system organization (as in the -old file system organization), -each disk drive contains one or more file systems. -A file system is described by its super-block, -located at the beginning of the file system's disk partition. -Because the super-block contains critical data, -it is replicated to protect against catastrophic loss. -This is done when the file system is created; -since the super-block data does not change, -the copies need not be referenced unless a head crash -or other hard disk error causes the default super-block -to be unusable. -.PP -To insure that it is possible to create files as large as -$2 sup 32$ bytes with only two levels of indirection, -the minimum size of a file system block is 4096 bytes. -The size of file system blocks can be any power of two -greater than or equal to 4096. -The block size of a file system is recorded in the -file system's super-block -so it is possible for file systems with different block sizes -to be simultaneously accessible on the same system. -The block size must be decided at the time that -the file system is created; -it cannot be subsequently changed without rebuilding the file system. -.PP -The new file system organization divides a disk partition -into one or more areas called -.I "cylinder groups". -A cylinder group is comprised of one or more consecutive -cylinders on a disk. -Associated with each cylinder group is some bookkeeping information -that includes a redundant copy of the super-block, -space for inodes, -a bit map describing available blocks in the cylinder group, -and summary information describing the usage of data blocks -within the cylinder group. -The bit map of available blocks in the cylinder group replaces -the traditional file system's free list. -For each cylinder group a static number of inodes -is allocated at file system creation time. -The default policy is to allocate one inode for each 2048 -bytes of space in the cylinder group, expecting this -to be far more than will ever be needed. -.PP -All the cylinder group bookkeeping information could be -placed at the beginning of each cylinder group. -However if this approach were used, -all the redundant information would be on the top platter. -A single hardware failure that destroyed the top platter -could cause the loss of all redundant copies of the super-block. -Thus the cylinder group bookkeeping information -begins at a varying offset from the beginning of the cylinder group. -The offset for each successive cylinder group is calculated to be -about one track further from the beginning of the cylinder group -than the preceding cylinder group. -In this way the redundant -information spirals down into the pack so that any single track, cylinder, -or platter can be lost without losing all copies of the super-block. -Except for the first cylinder group, -the space between the beginning of the cylinder group -and the beginning of the cylinder group information -is used for data blocks.\(dg -.FS -\(dg While it appears that the first cylinder group could be laid -out with its super-block at the ``known'' location, -this would not work for file systems -with blocks sizes of 16 kilobytes or greater. -This is because of a requirement that the first 8 kilobytes of the disk -be reserved for a bootstrap program and a separate requirement that -the cylinder group information begin on a file system block boundary. -To start the cylinder group on a file system block boundary, -file systems with block sizes larger than 8 kilobytes -would have to leave an empty space between the end of -the boot block and the beginning of the cylinder group. -Without knowing the size of the file system blocks, -the system would not know what roundup function to use -to find the beginning of the first cylinder group. -.FE -.NH 2 -Optimizing storage utilization -.PP -Data is laid out so that larger blocks can be transferred -in a single disk transaction, greatly increasing file system throughput. -As an example, consider a file in the new file system -composed of 4096 byte data blocks. -In the old file system this file would be composed of 1024 byte blocks. -By increasing the block size, disk accesses in the new file -system may transfer up to four times as much information per -disk transaction. -In large files, several -4096 byte blocks may be allocated from the same cylinder so that -even larger data transfers are possible before requiring a seek. -.PP -The main problem with -larger blocks is that most UNIX -file systems are composed of many small files. -A uniformly large block size wastes space. -Table 1 shows the effect of file system -block size on the amount of wasted space in the file system. -The files measured to obtain these figures reside on -one of our time sharing -systems that has roughly 1.2 gigabytes of on-line storage. -The measurements are based on the active user file systems containing -about 920 megabytes of formatted space. -.KF -.DS B -.TS -box; -l|l|l -a|n|l. -Space used % waste Organization -_ -775.2 Mb 0.0 Data only, no separation between files -807.8 Mb 4.2 Data only, each file starts on 512 byte boundary -828.7 Mb 6.9 Data + inodes, 512 byte block UNIX file system -866.5 Mb 11.8 Data + inodes, 1024 byte block UNIX file system -948.5 Mb 22.4 Data + inodes, 2048 byte block UNIX file system -1128.3 Mb 45.6 Data + inodes, 4096 byte block UNIX file system -.TE -Table 1 \- Amount of wasted space as a function of block size. -.DE -.KE -The space wasted is calculated to be the percentage of space -on the disk not containing user data. -As the block size on the disk -increases, the waste rises quickly, to an intolerable -45.6% waste with 4096 byte file system blocks. -.PP -To be able to use large blocks without undue waste, -small files must be stored in a more efficient way. -The new file system accomplishes this goal by allowing the division -of a single file system block into one or more -.I "fragments". -The file system fragment size is specified -at the time that the file system is created; -each file system block can optionally be broken into -2, 4, or 8 fragments, each of which is addressable. -The lower bound on the size of these fragments is constrained -by the disk sector size, -typically 512 bytes. -The block map associated with each cylinder group -records the space available in a cylinder group -at the fragment level; -to determine if a block is available, aligned fragments are examined. -Figure 1 shows a piece of a map from a 4096/1024 file system. -.KF -.DS B -.TS -box; -l|c c c c. -Bits in map XXXX XXOO OOXX OOOO -Fragment numbers 0-3 4-7 8-11 12-15 -Block numbers 0 1 2 3 -.TE -Figure 1 \- Example layout of blocks and fragments in a 4096/1024 file system. -.DE -.KE -Each bit in the map records the status of a fragment; -an ``X'' shows that the fragment is in use, -while a ``O'' shows that the fragment is available for allocation. -In this example, -fragments 0\-5, 10, and 11 are in use, -while fragments 6\-9, and 12\-15 are free. -Fragments of adjoining blocks cannot be used as a full block, -even if they are large enough. -In this example, -fragments 6\-9 cannot be allocated as a full block; -only fragments 12\-15 can be coalesced into a full block. -.PP -On a file system with a block size of 4096 bytes -and a fragment size of 1024 bytes, -a file is represented by zero or more 4096 byte blocks of data, -and possibly a single fragmented block. -If a file system block must be fragmented to obtain -space for a small amount of data, -the remaining fragments of the block are made -available for allocation to other files. -As an example consider an 11000 byte file stored on -a 4096/1024 byte file system. -This file would uses two full size blocks and one -three fragment portion of another block. -If no block with three aligned fragments is -available at the time the file is created, -a full size block is split yielding the necessary -fragments and a single unused fragment. -This remaining fragment can be allocated to another file as needed. -.PP -Space is allocated to a file when a program does a \fIwrite\fP -system call. -Each time data is written to a file, the system checks to see if -the size of the file has increased*. -.FS -* A program may be overwriting data in the middle of an existing file -in which case space would already have been allocated. -.FE -If the file needs to be expanded to hold the new data, -one of three conditions exists: -.IP 1) -There is enough space left in an already allocated -block or fragment to hold the new data. -The new data is written into the available space. -.IP 2) -The file contains no fragmented blocks (and the last -block in the file -contains insufficient space to hold the new data). -If space exists in a block already allocated, -the space is filled with new data. -If the remainder of the new data contains more than -a full block of data, a full block is allocated and -the first full block of new data is written there. -This process is repeated until less than a full block -of new data remains. -If the remaining new data to be written will -fit in less than a full block, -a block with the necessary fragments is located, -otherwise a full block is located. -The remaining new data is written into the located space. -.IP 3) -The file contains one or more fragments (and the -fragments contain insufficient space to hold the new data). -If the size of the new data plus the size of the data -already in the fragments exceeds the size of a full block, -a new block is allocated. -The contents of the fragments are copied -to the beginning of the block -and the remainder of the block is filled with new data. -The process then continues as in (2) above. -Otherwise, if the new data to be written will -fit in less than a full block, -a block with the necessary fragments is located, -otherwise a full block is located. -The contents of the existing fragments -appended with the new data -are written into the allocated space. -.PP -The problem with expanding a file one fragment at a -a time is that data may be copied many times as a -fragmented block expands to a full block. -Fragment reallocation can be minimized -if the user program writes a full block at a time, -except for a partial block at the end of the file. -Since file systems with different block sizes may reside on -the same system, -the file system interface has been extended to provide -application programs the optimal size for a read or write. -For files the optimal size is the block size of the file system -on which the file is being accessed. -For other objects, such as pipes and sockets, -the optimal size is the underlying buffer size. -This feature is used by the Standard -Input/Output Library, -a package used by most user programs. -This feature is also used by -certain system utilities such as archivers and loaders -that do their own input and output management -and need the highest possible file system bandwidth. -.PP -The amount of wasted space in the 4096/1024 byte new file system -organization is empirically observed to be about the same as in the -1024 byte old file system organization. -A file system with 4096 byte blocks and 512 byte fragments -has about the same amount of wasted space as the 512 byte -block UNIX file system. -The new file system uses less space -than the 512 byte or 1024 byte -file systems for indexing information for -large files and the same amount of space -for small files. -These savings are offset by the need to use -more space for keeping track of available free blocks. -The net result is about the same disk utilization -when a new file system's fragment size -equals an old file system's block size. -.PP -In order for the layout policies to be effective, -a file system cannot be kept completely full. -For each file system there is a parameter, termed -the free space reserve, that -gives the minimum acceptable percentage of file system -blocks that should be free. -If the number of free blocks drops below this level -only the system administrator can continue to allocate blocks. -The value of this parameter may be changed at any time, -even when the file system is mounted and active. -The transfer rates that appear in section 4 were measured on file -systems kept less than 90% full (a reserve of 10%). -If the number of free blocks falls to zero, -the file system throughput tends to be cut in half, -because of the inability of the file system to localize -blocks in a file. -If a file system's performance degrades because -of overfilling, it may be restored by removing -files until the amount of free space once again -reaches the minimum acceptable level. -Access rates for files created during periods of little -free space may be restored by moving their data once enough -space is available. -The free space reserve must be added to the -percentage of waste when comparing the organizations given -in Table 1. -Thus, the percentage of waste in -an old 1024 byte UNIX file system is roughly -comparable to a new 4096/512 byte file system -with the free space reserve set at 5%. -(Compare 11.8% wasted with the old file system -to 6.9% waste + 5% reserved space in the -new file system.) -.NH 2 -File system parameterization -.PP -Except for the initial creation of the free list, -the old file system ignores the parameters of the underlying hardware. -It has no information about either the physical characteristics -of the mass storage device, -or the hardware that interacts with it. -A goal of the new file system is to parameterize the -processor capabilities and -mass storage characteristics -so that blocks can be allocated in an -optimum configuration-dependent way. -Parameters used include the speed of the processor, -the hardware support for mass storage transfers, -and the characteristics of the mass storage devices. -Disk technology is constantly improving and -a given installation can have several different disk technologies -running on a single processor. -Each file system is parameterized so that it can be -adapted to the characteristics of the disk on which -it is placed. -.PP -For mass storage devices such as disks, -the new file system tries to allocate new blocks -on the same cylinder as the previous block in the same file. -Optimally, these new blocks will also be -rotationally well positioned. -The distance between ``rotationally optimal'' blocks varies greatly; -it can be a consecutive block -or a rotationally delayed block -depending on system characteristics. -On a processor with an input/output channel that does not require -any processor intervention between mass storage transfer requests, -two consecutive disk blocks can often be accessed -without suffering lost time because of an intervening disk revolution. -For processors without input/output channels, -the main processor must field an interrupt and -prepare for a new disk transfer. -The expected time to service this interrupt and -schedule a new disk transfer depends on the -speed of the main processor. -.PP -The physical characteristics of each disk include -the number of blocks per track and the rate at which -the disk spins. -The allocation routines use this information to calculate -the number of milliseconds required to skip over a block. -The characteristics of the processor include -the expected time to service an interrupt and schedule a -new disk transfer. -Given a block allocated to a file, -the allocation routines calculate the number of blocks to -skip over so that the next block in the file will -come into position under the disk head in the expected -amount of time that it takes to start a new -disk transfer operation. -For programs that sequentially access large amounts of data, -this strategy minimizes the amount of time spent waiting for -the disk to position itself. -.PP -To ease the calculation of finding rotationally optimal blocks, -the cylinder group summary information includes -a count of the available blocks in a cylinder -group at different rotational positions. -Eight rotational positions are distinguished, -so the resolution of the -summary information is 2 milliseconds for a typical 3600 -revolution per minute drive. -The super-block contains a vector of lists called -.I "rotational layout tables". -The vector is indexed by rotational position. -Each component of the vector -lists the index into the block map for every data block contained -in its rotational position. -When looking for an allocatable block, -the system first looks through the summary counts for a rotational -position with a non-zero block count. -It then uses the index of the rotational position to find the appropriate -list to use to index through -only the relevant parts of the block map to find a free block. -.PP -The parameter that defines the -minimum number of milliseconds between the completion of a data -transfer and the initiation of -another data transfer on the same cylinder -can be changed at any time, -even when the file system is mounted and active. -If a file system is parameterized to lay out blocks with -a rotational separation of 2 milliseconds, -and the disk pack is then moved to a system that has a -processor requiring 4 milliseconds to schedule a disk operation, -the throughput will drop precipitously because of lost disk revolutions -on nearly every block. -If the eventual target machine is known, -the file system can be parameterized for it -even though it is initially created on a different processor. -Even if the move is not known in advance, -the rotational layout delay can be reconfigured after the disk is moved -so that all further allocation is done based on the -characteristics of the new host. -.NH 2 -Layout policies -.PP -The file system layout policies are divided into two distinct parts. -At the top level are global policies that use file system -wide summary information to make decisions regarding -the placement of new inodes and data blocks. -These routines are responsible for deciding the -placement of new directories and files. -They also calculate rotationally optimal block layouts, -and decide when to force a long seek to a new cylinder group -because there are insufficient blocks left -in the current cylinder group to do reasonable layouts. -Below the global policy routines are -the local allocation routines that use a locally optimal scheme to -lay out data blocks. -.PP -Two methods for improving file system performance are to increase -the locality of reference to minimize seek latency -as described by [Trivedi80], and -to improve the layout of data to make larger transfers possible -as described by [Nevalainen77]. -The global layout policies try to improve performance -by clustering related information. -They cannot attempt to localize all data references, -but must also try to spread unrelated data -among different cylinder groups. -If too much localization is attempted, -the local cylinder group may run out of space -forcing the data to be scattered to non-local cylinder groups. -Taken to an extreme, -total localization can result in a single huge cluster of data -resembling the old file system. -The global policies try to balance the two conflicting -goals of localizing data that is concurrently accessed -while spreading out unrelated data. -.PP -One allocatable resource is inodes. -Inodes are used to describe both files and directories. -Inodes of files in the same directory are frequently accessed together. -For example, the ``list directory'' command often accesses -the inode for each file in a directory. -The layout policy tries to place all the inodes of -files in a directory in the same cylinder group. -To ensure that files are distributed throughout the disk, -a different policy is used for directory allocation. -A new directory is placed in a cylinder group that has a greater -than average number of free inodes, -and the smallest number of directories already in it. -The intent of this policy is to allow the inode clustering policy -to succeed most of the time. -The allocation of inodes within a cylinder group is done using a -next free strategy. -Although this allocates the inodes randomly within a cylinder group, -all the inodes for a particular cylinder group can be read with -8 to 16 disk transfers. -(At most 16 disk transfers are required because a cylinder -group may have no more than 2048 inodes.) -This puts a small and constant upper bound on the number of -disk transfers required to access the inodes -for all the files in a directory. -In contrast, the old file system typically requires -one disk transfer to fetch the inode for each file in a directory. -.PP -The other major resource is data blocks. -Since data blocks for a file are typically accessed together, -the policy routines try to place all data -blocks for a file in the same cylinder group, -preferably at rotationally optimal positions in the same cylinder. -The problem with allocating all the data blocks -in the same cylinder group is that large files will -quickly use up available space in the cylinder group, -forcing a spill over to other areas. -Further, using all the space in a cylinder group -causes future allocations for any file in the cylinder group -to also spill to other areas. -Ideally none of the cylinder groups should ever become completely full. -The heuristic solution chosen is to -redirect block allocation -to a different cylinder group -when a file exceeds 48 kilobytes, -and at every megabyte thereafter.* -.FS -* The first spill over point at 48 kilobytes is the point -at which a file on a 4096 byte block file system first -requires a single indirect block. This appears to be -a natural first point at which to redirect block allocation. -The other spillover points are chosen with the intent of -forcing block allocation to be redirected when a -file has used about 25% of the data blocks in a cylinder group. -In observing the new file system in day to day use, the heuristics appear -to work well in minimizing the number of completely filled -cylinder groups. -.FE -The newly chosen cylinder group is selected from those cylinder -groups that have a greater than average number of free blocks left. -Although big files tend to be spread out over the disk, -a megabyte of data is typically accessible before -a long seek must be performed, -and the cost of one long seek per megabyte is small. -.PP -The global policy routines call local allocation routines with -requests for specific blocks. -The local allocation routines will -always allocate the requested block -if it is free, otherwise it -allocates a free block of the requested size that is -rotationally closest to the requested block. -If the global layout policies had complete information, -they could always request unused blocks and -the allocation routines would be reduced to simple bookkeeping. -However, maintaining complete information is costly; -thus the implementation of the global layout policy -uses heuristics that employ only partial information. -.PP -If a requested block is not available, the local allocator uses -a four level allocation strategy: -.IP 1) -Use the next available block rotationally closest -to the requested block on the same cylinder. It is assumed -here that head switching time is zero. On disk -controllers where this is not the case, it may be possible -to incorporate the time required to switch between disk platters -when constructing the rotational layout tables. This, however, -has not yet been tried. -.IP 2) -If there are no blocks available on the same cylinder, -use a block within the same cylinder group. -.IP 3) -If that cylinder group is entirely full, -quadratically hash the cylinder group number to choose -another cylinder group to look for a free block. -.IP 4) -Finally if the hash fails, apply an exhaustive search -to all cylinder groups. -.PP -Quadratic hash is used because of its speed in finding -unused slots in nearly full hash tables [Knuth75]. -File systems that are parameterized to maintain at least -10% free space rarely use this strategy. -File systems that are run without maintaining any free -space typically have so few free blocks that almost any -allocation is random; -the most important characteristic of -the strategy used under such conditions is that the strategy be fast. -.ds RH Performance -.sp 2 -.ne 1i diff --git a/share/doc/smm/05.fastfs/4.t b/share/doc/smm/05.fastfs/4.t deleted file mode 100644 index a6e9c5c52cb..00000000000 --- a/share/doc/smm/05.fastfs/4.t +++ /dev/null @@ -1,250 +0,0 @@ -.\" $OpenBSD: 4.t,v 1.3 2003/06/02 23:30:11 millert Exp $ -.\" -.\" Copyright (c) 1986, 1993 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" -.\" @(#)4.t 8.1 (Berkeley) 6/8/93 -.\" -.ds RH Performance -.NH -Performance -.PP -Ultimately, the proof of the effectiveness of the -algorithms described in the previous section -is the long term performance of the new file system. -.PP -Our empirical studies have shown that the inode layout policy has -been effective. -When running the ``list directory'' command on a large directory -that itself contains many directories (to force the system -to access inodes in multiple cylinder groups), -the number of disk accesses for inodes is cut by a factor of two. -The improvements are even more dramatic for large directories -containing only files, -disk accesses for inodes being cut by a factor of eight. -This is most encouraging for programs such as spooling daemons that -access many small files, -since these programs tend to flood the -disk request queue on the old file system. -.PP -Table 2 summarizes the measured throughput of the new file system. -Several comments need to be made about the conditions under which these -tests were run. -The test programs measure the rate at which user programs can transfer -data to or from a file without performing any processing on it. -These programs must read and write enough data to -insure that buffering in the -operating system does not affect the results. -They are also run at least three times in succession; -the first to get the system into a known state -and the second two to insure that the -experiment has stabilized and is repeatable. -The tests used and their results are -discussed in detail in [Kridle83]\(dg. -.FS -\(dg A UNIX command that is similar to the reading test that we used is -``cp file /dev/null'', where ``file'' is eight megabytes long. -.FE -The systems were running multi-user but were otherwise quiescent. -There was no contention for either the CPU or the disk arm. -The only difference between the UNIBUS and MASSBUS tests -was the controller. -All tests used an AMPEX Capricorn 330 megabyte Winchester disk. -As Table 2 shows, all file system test runs were on a VAX 11/750. -All file systems had been in production use for at least -a month before being measured. -The same number of system calls were performed in all tests; -the basic system call overhead was a negligible portion of -the total running time of the tests. -.KF -.DS B -.TS -box; -c c|c s s -c c|c c c. -Type of Processor and Read -File System Bus Measured Speed Bandwidth % CPU -_ -old 1024 750/UNIBUS 29 Kbytes/sec 29/983 3% 11% -new 4096/1024 750/UNIBUS 221 Kbytes/sec 221/983 22% 43% -new 8192/1024 750/UNIBUS 233 Kbytes/sec 233/983 24% 29% -new 4096/1024 750/MASSBUS 466 Kbytes/sec 466/983 47% 73% -new 8192/1024 750/MASSBUS 466 Kbytes/sec 466/983 47% 54% -.TE -.ce 1 -Table 2a \- Reading rates of the old and new UNIX file systems. -.TS -box; -c c|c s s -c c|c c c. -Type of Processor and Write -File System Bus Measured Speed Bandwidth % CPU -_ -old 1024 750/UNIBUS 48 Kbytes/sec 48/983 5% 29% -new 4096/1024 750/UNIBUS 142 Kbytes/sec 142/983 14% 43% -new 8192/1024 750/UNIBUS 215 Kbytes/sec 215/983 22% 46% -new 4096/1024 750/MASSBUS 323 Kbytes/sec 323/983 33% 94% -new 8192/1024 750/MASSBUS 466 Kbytes/sec 466/983 47% 95% -.TE -.ce 1 -Table 2b \- Writing rates of the old and new UNIX file systems. -.DE -.KE -.PP -Unlike the old file system, -the transfer rates for the new file system do not -appear to change over time. -The throughput rate is tied much more strongly to the -amount of free space that is maintained. -The measurements in Table 2 were based on a file system -with a 10% free space reserve. -Synthetic work loads suggest that throughput deteriorates -to about half the rates given in Table 2 when the file -systems are full. -.PP -The percentage of bandwidth given in Table 2 is a measure -of the effective utilization of the disk by the file system. -An upper bound on the transfer rate from the disk is calculated -by multiplying the number of bytes on a track by the number -of revolutions of the disk per second. -The bandwidth is calculated by comparing the data rates -the file system is able to achieve as a percentage of this rate. -Using this metric, the old file system is only -able to use about 3\-5% of the disk bandwidth, -while the new file system uses up to 47% -of the bandwidth. -.PP -Both reads and writes are faster in the new system than in the old system. -The biggest factor in this speedup is because of the larger -block size used by the new file system. -The overhead of allocating blocks in the new system is greater -than the overhead of allocating blocks in the old system, -however fewer blocks need to be allocated in the new system -because they are bigger. -The net effect is that the cost per byte allocated is about -the same for both systems. -.PP -In the new file system, the reading rate is always at least -as fast as the writing rate. -This is to be expected since the kernel must do more work when -allocating blocks than when simply reading them. -Note that the write rates are about the same -as the read rates in the 8192 byte block file system; -the write rates are slower than the read rates in the 4096 byte block -file system. -The slower write rates occur because -the kernel has to do twice as many disk allocations per second, -making the processor unable to keep up with the disk transfer rate. -.PP -In contrast the old file system is about 50% -faster at writing files than reading them. -This is because the write system call is asynchronous and -the kernel can generate disk transfer -requests much faster than they can be serviced, -hence disk transfers queue up in the disk buffer cache. -Because the disk buffer cache is sorted by minimum seek distance, -the average seek between the scheduled disk writes is much -less than it would be if the data blocks were written out -in the random disk order in which they are generated. -However when the file is read, -the read system call is processed synchronously so -the disk blocks must be retrieved from the disk in the -non-optimal seek order in which they are requested. -This forces the disk scheduler to do long -seeks resulting in a lower throughput rate. -.PP -In the new system the blocks of a file are more optimally -ordered on the disk. -Even though reads are still synchronous, -the requests are presented to the disk in a much better order. -Even though the writes are still asynchronous, -they are already presented to the disk in minimum seek -order so there is no gain to be had by reordering them. -Hence the disk seek latencies that limited the old file system -have little effect in the new file system. -The cost of allocation is the factor in the new system that -causes writes to be slower than reads. -.PP -The performance of the new file system is currently -limited by memory to memory copy operations -required to move data from disk buffers in the -system's address space to data buffers in the user's -address space. These copy operations account for -about 40% of the time spent performing an input/output operation. -If the buffers in both address spaces were properly aligned, -this transfer could be performed without copying by -using the VAX virtual memory management hardware. -This would be especially desirable when transferring -large amounts of data. -We did not implement this because it would change the -user interface to the file system in two major ways: -user programs would be required to allocate buffers on page boundaries, -and data would disappear from buffers after being written. -.PP -Greater disk throughput could be achieved by rewriting the disk drivers -to chain together kernel buffers. -This would allow contiguous disk blocks to be read -in a single disk transaction. -Many disks used with UNIX systems contain either -32 or 48 512 byte sectors per track. -Each track holds exactly two or three 8192 byte file system blocks, -or four or six 4096 byte file system blocks. -The inability to use contiguous disk blocks -effectively limits the performance -on these disks to less than 50% of the available bandwidth. -If the next block for a file cannot be laid out contiguously, -then the minimum spacing to the next allocatable -block on any platter is between a sixth and a half a revolution. -The implication of this is that the best possible layout without -contiguous blocks uses only half of the bandwidth of any given track. -If each track contains an odd number of sectors, -then it is possible to resolve the rotational delay to any number of sectors -by finding a block that begins at the desired -rotational position on another track. -The reason that block chaining has not been implemented is because it -would require rewriting all the disk drivers in the system, -and the current throughput rates are already limited by the -speed of the available processors. -.PP -Currently only one block is allocated to a file at a time. -A technique used by the DEMOS file system -when it finds that a file is growing rapidly, -is to preallocate several blocks at once, -releasing them when the file is closed if they remain unused. -By batching up allocations, the system can reduce the -overhead of allocating at each write, -and it can cut down on the number of disk writes needed to -keep the block pointers on the disk -synchronized with the block allocation [Powell79]. -This technique was not included because block allocation -currently accounts for less than 10% of the time spent in -a write system call and, once again, the -current throughput rates are already limited by the speed -of the available processors. -.ds RH Functional enhancements -.sp 2 -.ne 1i diff --git a/share/doc/smm/05.fastfs/5.t b/share/doc/smm/05.fastfs/5.t deleted file mode 100644 index 3512a9eddd0..00000000000 --- a/share/doc/smm/05.fastfs/5.t +++ /dev/null @@ -1,291 +0,0 @@ -.\" $OpenBSD: 5.t,v 1.3 2003/06/02 23:30:11 millert Exp $ -.\" -.\" Copyright (c) 1986, 1993 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" -.\" @(#)5.t 8.1 (Berkeley) 6/8/93 -.\" -.ds RH Functional enhancements -.NH -File system functional enhancements -.PP -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 -required all existing file systems to -be dumped and restored, -these functional enhancements were introduced at this time. -.NH 2 -Long file names -.PP -File names can now be of nearly arbitrary length. -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 -access routines have been introduced to provide a consistent -interface to directories on both old and new systems. -.PP -Directories are allocated in 512 byte units called chunks. -This size is chosen so that each allocation can be transferred -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 -file had to use a separate ``lock'' file. -A process would try to create a ``lock'' file. -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. -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, -so were forced to use a different mechanism. -While it is possible to get around all these problems, -the solutions are not straight forward, -so a mechanism for locking files has been added. -.PP -The most general schemes allow multiple processes -to concurrently update a file. -Several of these techniques are discussed in [Peterson83]. -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]. -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 -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. -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 -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 -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 -.I shared -or -.I exclusive -locks on files. -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, -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, -another process may access the file. -.PP -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 -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 -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 -wants only to check if a lock is present would require a separate -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. -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. -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. -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). -.NH 2 -Symbolic links -.PP -The traditional UNIX file system allows multiple -directory entries in the same file system -to reference a single file. Each directory entry -``links'' a file's name to an inode and its contents. -The link concept is fundamental; -inodes do not reside in directories, but exist separately and -are referenced by links. -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" -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 -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. -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. -.PP -Normally programs do not want to be aware that there is a -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 -symbolic links; seven system utilities required changes -to use these calls. -.PP -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 -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 -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. -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 -.PP -The UNIX system has traditionally attempted to share all available -resources to the greatest extent possible. -Thus any single user can allocate all the available space -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. -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. -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, -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. -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. -.ds RH Acknowledgements -.sp 2 -.ne 1i diff --git a/share/doc/smm/05.fastfs/6.t b/share/doc/smm/05.fastfs/6.t deleted file mode 100644 index 7bd8c56e62c..00000000000 --- a/share/doc/smm/05.fastfs/6.t +++ /dev/null @@ -1,157 +0,0 @@ -.\" $OpenBSD: 6.t,v 1.3 2003/06/02 23:30:11 millert Exp $ -.\" -.\" Copyright (c) 1986, 1993 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" -.\" @(#)6.t 8.1 (Berkeley) 6/8/93 -.\" -.nr H2 1 -.ds RH Acknowledgements -.SH -\s+2Acknowledgements\s0 -.PP -We thank Robert Elz for his ongoing interest in the new file system, -and for adding disk quotas in a rational and efficient manner. -We also acknowledge Dennis Ritchie for his suggestions -on the appropriate modifications to the user interface. -We appreciate Michael Powell's explanations on how -the DEMOS file system worked; -many of his ideas were used in this implementation. -Special commendation goes to Peter Kessler and Robert Henry for acting -like real users during the early debugging stage when file systems were -less stable than they should have been. -The criticisms and suggestions by the reviews contributed significantly -to the coherence of the paper. -Finally we thank our sponsors, -the National Science Foundation under grant MCS80-05144, -and the Defense Advance Research Projects Agency (DoD) under -ARPA Order No. 4031 monitored by Naval Electronic System Command under -Contract No. N00039-82-C-0235. -.ds RH References -.nr H2 1 -.sp 2 -.SH -\s+2References\s0 -.LP -.IP [Almes78] 20 -Almes, G., and Robertson, G. -"An Extensible File System for Hydra" -Proceedings of the Third International Conference on Software Engineering, -IEEE, May 1978. -.IP [Bass81] 20 -Bass, J. -"Implementation Description for File Locking", -Onyx Systems Inc, 73 E. Trimble Rd, San Jose, CA 95131 -Jan 1981. -.IP [Feiertag71] 20 -Feiertag, R. J. and Organick, E. I., -"The Multics Input-Output System", -Proceedings of the Third Symposium on Operating Systems Principles, -ACM, Oct 1971. pp 35-41 -.IP [Ferrin82a] 20 -Ferrin, T.E., -"Performance and Robustness Improvements in Version 7 UNIX", -Computer Graphics Laboratory Technical Report 2, -School of Pharmacy, University of California, -San Francisco, January 1982. -Presented at the 1982 Winter Usenix Conference, Santa Monica, California. -.IP [Ferrin82b] 20 -Ferrin, T.E., -"Performance Issuses of VMUNIX Revisited", -;login: (The Usenix Association Newsletter), Vol 7, #5, November 1982. pp 3-6 -.IP [Kridle83] 20 -Kridle, R., and McKusick, M., -"Performance Effects of Disk Subsystem Choices for -VAX Systems Running 4.2BSD UNIX", -Computer Systems Research Group, Dept of EECS, Berkeley, CA 94720, -Technical Report #8. -.IP [Kowalski78] 20 -Kowalski, T. -"FSCK - The UNIX System Check Program", -Bell Laboratory, Murray Hill, NJ 07974. March 1978 -.IP [Knuth75] 20 -Kunth, D. -"The Art of Computer Programming", -Volume 3 - Sorting and Searching, -Addison-Wesley Publishing Company Inc, Reading, Mass, 1975. pp 506-549 -.IP [Maruyama76] -Maruyama, K., and Smith, S. -"Optimal reorganization of Distributed Space Disk Files", -CACM, 19, 11. Nov 1976. pp 634-642 -.IP [Nevalainen77] 20 -Nevalainen, O., Vesterinen, M. -"Determining Blocking Factors for Sequential Files by Heuristic Methods", -The Computer Journal, 20, 3. Aug 1977. pp 245-247 -.IP [Pechura83] 20 -Pechura, M., and Schoeffler, J. -"Estimating File Access Time of Floppy Disks", -CACM, 26, 10. Oct 1983. pp 754-763 -.IP [Peterson83] 20 -Peterson, G. -"Concurrent Reading While Writing", -ACM Transactions on Programming Languages and Systems, -ACM, 5, 1. Jan 1983. pp 46-55 -.IP [Powell79] 20 -Powell, M. -"The DEMOS File System", -Proceedings of the Sixth Symposium on Operating Systems Principles, -ACM, Nov 1977. pp 33-42 -.IP [Ritchie74] 20 -Ritchie, D. M. and Thompson, K., -"The UNIX Time-Sharing System", -CACM 17, 7. July 1974. pp 365-375 -.IP [Smith81a] 20 -Smith, A. -"Input/Output Optimization and Disk Architectures: A Survey", -Performance and Evaluation 1. Jan 1981. pp 104-117 -.IP [Smith81b] 20 -Smith, A. -"Bibliography on File and I/O System Optimization and Related Topics", -Operating Systems Review, 15, 4. Oct 1981. pp 39-54 -.IP [Symbolics81] 20 -"Symbolics File System", -Symbolics Inc, 9600 DeSoto Ave, Chatsworth, CA 91311 -Aug 1981. -.IP [Thompson78] 20 -Thompson, K. -"UNIX Implementation", -Bell System Technical Journal, 57, 6, part 2. pp 1931-1946 -July-August 1978. -.IP [Thompson80] 20 -Thompson, M. -"Spice File System", -Carnegie-Mellon University, -Department of Computer Science, Pittsburg, PA 15213 -#CMU-CS-80, Sept 1980. -.IP [Trivedi80] 20 -Trivedi, K. -"Optimal Selection of CPU Speed, Device Capabilities, and File Assignments", -Journal of the ACM, 27, 3. July 1980. pp 457-473 -.IP [White80] 20 -White, R. M. -"Disk Storage Technology", -Scientific American, 243(2), August 1980. diff --git a/share/doc/smm/05.fastfs/Makefile b/share/doc/smm/05.fastfs/Makefile deleted file mode 100644 index 30c7574d66a..00000000000 --- a/share/doc/smm/05.fastfs/Makefile +++ /dev/null @@ -1,14 +0,0 @@ -# $OpenBSD: Makefile,v 1.3 2004/02/01 14:22:45 jmc Exp $ - - -DIR= smm/05.fastfs -SRCS= 0.t 1.t 2.t 3.t 4.t 5.t 6.t -MACROS= -ms - -paper.ps: ${SRCS} - ${TBL} ${SRCS} | ${EQN} | ${ROFF} > ${.TARGET} - -paper.txt: ${SRCS} - ${TBL} ${SRCS} | ${EQN} | ${ROFF} -Tascii > ${.TARGET} - -.include <bsd.doc.mk> diff --git a/share/doc/smm/Makefile b/share/doc/smm/Makefile deleted file mode 100644 index e5333a2cd14..00000000000 --- a/share/doc/smm/Makefile +++ /dev/null @@ -1,11 +0,0 @@ -# $OpenBSD: Makefile,v 1.9 2010/07/01 20:02:28 tedu Exp $ -# from: @(#)Makefile 8.1 (Berkeley) 6/10/93 - -DOCDIR= /usr/share/doc/smm -FILES= Makefile - -beforeinstall: - install -c -o ${DOCOWN} -g ${DOCGRP} -m ${DOCMODE} ${FILES} \ - ${DESTDIR}${DOCDIR} - -.include <bsd.subdir.mk> diff --git a/share/doc/usd/Makefile b/share/doc/usd/Makefile deleted file mode 100644 index 3c8febd9a61..00000000000 --- a/share/doc/usd/Makefile +++ /dev/null @@ -1,10 +0,0 @@ -# $OpenBSD: Makefile,v 1.10 2010/07/01 20:08:54 tedu Exp $ - -DOCDIR= /usr/share/doc/usd -FILES= Makefile - -beforeinstall: - install -c -o ${DOCOWN} -g ${DOCGRP} -m ${DOCMODE} ${FILES} \ - ${DESTDIR}${DOCDIR} - -.include <bsd.subdir.mk> |