diff options
author | schweikh <schweikh@FreeBSD.org> | 2003-01-01 18:49:04 +0000 |
---|---|---|
committer | schweikh <schweikh@FreeBSD.org> | 2003-01-01 18:49:04 +0000 |
commit | d3367c5f5d3ddcc6824d8f41c4cf179f9a5588f8 (patch) | |
tree | f412dafc7d29429919e8770cdefeb37441fc1299 /share/doc/smm | |
parent | 718a7892bc6da2237db71c255051dd54a4e93a92 (diff) | |
download | FreeBSD-src-d3367c5f5d3ddcc6824d8f41c4cf179f9a5588f8.zip FreeBSD-src-d3367c5f5d3ddcc6824d8f41c4cf179f9a5588f8.tar.gz |
Correct typos, mostly s/ a / an / where appropriate. Some whitespace cleanup,
especially in troff files.
Diffstat (limited to 'share/doc/smm')
-rw-r--r-- | share/doc/smm/01.setup/3.t | 28 | ||||
-rw-r--r-- | share/doc/smm/05.fastfs/3.t | 42 | ||||
-rw-r--r-- | share/doc/smm/06.nfs/1.t | 2 | ||||
-rw-r--r-- | share/doc/smm/06.nfs/2.t | 6 | ||||
-rw-r--r-- | share/doc/smm/18.net/7.t | 4 |
5 files changed, 44 insertions, 38 deletions
diff --git a/share/doc/smm/01.setup/3.t b/share/doc/smm/01.setup/3.t index 54531ad..0f3e859 100644 --- a/share/doc/smm/01.setup/3.t +++ b/share/doc/smm/01.setup/3.t @@ -380,7 +380,7 @@ the kernel will use .Pn \*(Dk1a as its root filesystem. If .Pn /dev/\*(Dk1b -is configured as a swap partition, +is configured as a swap partition, it will be used as the initial swap area, otherwise the normal primary swap area (\c .Pn /dev/\*(Dk0b ) @@ -489,7 +489,7 @@ tape, extract them into a scratch directory, say .PP The data files marked in the previous table with a dagger (\(dg) may be used without change from the previous system. -Those data files marked with a double dagger (\(dd) have syntax +Those data files marked with a double dagger (\(dd) have syntax changes or substantial enhancements. You should start with the \*(4B version and carefully integrate any local changes into the new file. @@ -605,8 +605,8 @@ _ _ _ /etc/passwd /etc/master.passwd new format; see below /usr/lib/sendmail.cf /etc/sendmail.cf changed pathnames /usr/lib/aliases /etc/aliases may contain changed pathnames -/etc/*.pid /var/run/*.pid - +/etc/*.pid /var/run/*.pid + .T& l l l lfC lfC l. @@ -859,7 +859,7 @@ The ``daemon'' user is used for daemon processes that do not need root privileges. The ``operator'' user-id is used as an account for dumpers so that they can log in without having the root password. -By placing them in the ``operator'' group, +By placing them in the ``operator'' group, they can get read access to the disks. The ``uucp'' login has existed long before \*(4B, and is noted here just to provide a common user-id. @@ -1002,7 +1002,7 @@ privilege to set kernel state. .Sh 3 "Security" .PP The kernel runs with four different levels of security. -Any superuser process can raise the security level, but only +Any superuser process can raise the security level, but only .Fn init (8) can lower it. Security levels are defined as follows: @@ -1027,7 +1027,7 @@ but also inhibits running while the system is multi-user. See .Xr chflags (1) -and the \-\fBo\fP option to +and the \-\fBo\fP option to .Xr ls (1) for information on setting and displaying the immutable and append-only flags. @@ -1165,14 +1165,14 @@ structure into the kernel (e.g. .Fn sendto and .Fn connect ) -have a separate parameter that specifies the +have a separate parameter that specifies the .I sockaddr length, and thus it is not necessary to fill in the .I sa_len field for those system calls. System calls that pass a .I sockaddr -structure back from the kernel (e.g. +structure back from the kernel (e.g. .Fn recvfrom and .Fn accept ) @@ -1319,7 +1319,7 @@ See and .Xr lfs_cleanerd (8) for more information. -For a in-depth description of the implementation and performance +For an in-depth description of the implementation and performance characteristics of log-structured filesystems in general, and this one in particular, see Dr. Margo Seltzer's doctoral thesis, available from the University of California Computer Science Department. @@ -1328,7 +1328,7 @@ We have also added a memory-based filesystem that runs in pageable memory, allowing large temporary filesystems without requiring dedicated physical memory. .PP -The local ``fast filesystem'' has been enhanced to do +The local ``fast filesystem'' has been enhanced to do clustering that allows large pieces of files to be allocated contiguously resulting in near doubling of filesystem throughput. @@ -1355,7 +1355,7 @@ When set on a file, .Xr dump (8) will omit the file from incremental backups but retain them on full backups. -See the ``-h'' flag to +See the ``-h'' flag to .Xr dump (8) for details on how to change this default. The ``nodump'' flag is usually set on core dumps, @@ -1867,7 +1867,7 @@ yacc A new, freely redistributable, significantly faster version. .PP The new versions of .Xr lex (1) -(``flex'') and +(``flex'') and .Xr yacc (1) (``zoo'') should be installed early on if attempting to cross-compile \*(4B on another system. @@ -1889,7 +1889,7 @@ for an example of their use. .Sh 2 "Hints on converting from \*(Ps to \*(4B" .PP This section summarizes changes between -\*(Ps and \*(4B that are likely to +\*(Ps and \*(4B that are likely to cause difficulty in doing the conversion. It does not include changes in the network; see section 5 for information on setting up the network. diff --git a/share/doc/smm/05.fastfs/3.t b/share/doc/smm/05.fastfs/3.t index e2ac4ba..23db86a 100644 --- a/share/doc/smm/05.fastfs/3.t +++ b/share/doc/smm/05.fastfs/3.t @@ -31,6 +31,8 @@ .\" .\" @(#)3.t 8.1 (Berkeley) 6/8/93 .\" +.\" $FreeBSD$ +.\" .ds RH New file system .NH New file system organization @@ -55,7 +57,7 @@ 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 +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. @@ -80,7 +82,7 @@ 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. +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. @@ -109,7 +111,7 @@ 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 +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, @@ -131,7 +133,7 @@ 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 +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. @@ -197,7 +199,7 @@ Figure 1 \- Example layout of blocks and fragments in a 4096/1024 file system. .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. +while an ``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. @@ -256,7 +258,7 @@ 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 +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, @@ -274,7 +276,7 @@ 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 +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, @@ -345,7 +347,7 @@ 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 +.NH 2 File system parameterization .PP Except for the initial creation of the free list, @@ -353,11 +355,11 @@ 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 +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. +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. @@ -370,8 +372,8 @@ 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 +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 @@ -439,7 +441,7 @@ 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, +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, @@ -464,7 +466,7 @@ 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 +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]. @@ -486,7 +488,7 @@ while spreading out unrelated data. 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 +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. @@ -547,10 +549,10 @@ 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 +The global policy routines call local allocation routines with requests for specific blocks. The local allocation routines will -always allocate the requested block +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. @@ -558,7 +560,7 @@ 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 +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 @@ -566,7 +568,7 @@ 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 +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, @@ -575,7 +577,7 @@ has not yet been tried. 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, +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) diff --git a/share/doc/smm/06.nfs/1.t b/share/doc/smm/06.nfs/1.t index 0806cad..57d1b9c 100644 --- a/share/doc/smm/06.nfs/1.t +++ b/share/doc/smm/06.nfs/1.t @@ -85,7 +85,7 @@ use of the Sun RPC library. .sh 1 "Mount Problems" .pp There are several problems that can be encountered at the time of an NFS -mount, ranging from a unresponsive NFS server (crashed, network partitioned +mount, ranging from an unresponsive NFS server (crashed, network partitioned from client, etc.) to various interoperability problems between different NFS implementations. .pp diff --git a/share/doc/smm/06.nfs/2.t b/share/doc/smm/06.nfs/2.t index 841dd5f..85e2896 100644 --- a/share/doc/smm/06.nfs/2.t +++ b/share/doc/smm/06.nfs/2.t @@ -34,6 +34,8 @@ .\" .\" @(#)2.t 8.1 (Berkeley) 6/8/93 .\" +.\" $FreeBSD$ +.\" .sh 1 "Not Quite NFS, Crash Tolerant Cache Consistency for NFS" .pp Not Quite NFS (NQNFS) is an NFS like protocol designed to maintain full cache @@ -127,7 +129,7 @@ the number of seconds the server is willing to wait for a client with an expired write caching lease to push dirty writes. .pp The server maintains a \fBmodify_revision\fR number for each file. It is -defined as a unsigned quadword integer that is never zero and that must +defined as an unsigned quadword integer that is never zero and that must increase whenever the corresponding file is modified on the server. It is used by the client to determine whether or not cached data for the file is @@ -400,7 +402,7 @@ modifyrev .(l typedef unsigned hyper modifyrev; .)l -The "modifyrev" is a unsigned quadword integer value that is never zero +The "modifyrev" is an unsigned quadword integer value that is never zero and increases every time the corresponding file is modified on the server. .ip \(bu nqnfs_time diff --git a/share/doc/smm/18.net/7.t b/share/doc/smm/18.net/7.t index 8ccecc8..e165de0 100644 --- a/share/doc/smm/18.net/7.t +++ b/share/doc/smm/18.net/7.t @@ -31,6 +31,8 @@ .\" .\" @(#)7.t 8.1 (Berkeley) 6/8/93 .\" +.\" $FreeBSD$ +.\" .nr H2 1 .br .ne 30v @@ -115,7 +117,7 @@ to carry out this request (if possible). A ``listen'' request always precedes a request to accept a connection. .IP PRU_CONNECT .br -The ``connect'' request indicates the user wants to a establish +The ``connect'' request indicates the user wants to establish an association. The \fIaddr\fP parameter supplied describes the peer to be connected to. The effect of a connect request may vary depending on the protocol. Virtual circuit protocols, |