os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Fix the following typos:

Browse source 
metadata     -> meta-data
i-nodes      -> inodes
hierachies   -> hierarchies
i. e.        -> i.e.
soft updates -> Soft Updates
This commit is contained in:
Tom Hukins 2002-02-28 22:27:15 +00:00
parent 8430c3ef83
commit c8817a56e8
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=12332
1 changed files with 19 additions and 19 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

38
en_US.ISO8859-1/books/handbook/config/chapter.sgml
View file

@ -907,11 +907,11 @@ kern.maxfiles: 2088 -> 5000</screen>
<indexterm><primary>Soft Updates (Details)</primary></indexterm> <indexterm><primary>Soft Updates (Details)</primary></indexterm>
<para>There are two traditional approaches to writing a filesystem's meta-data <para>There are two traditional approaches to writing a filesystem's meta-data
back to disk. (Metadata updates are updates to back to disk. (Meta-data updates are updates to
non-content data like i-nodes or directories.)</para> non-content data like inodes or directories.)</para>
<para>Historically, the default behaviour was to write out <para>Historically, the default behaviour was to write out
metadata updates synchronously. If a directory had been meta-data updates synchronously. If a directory had been
changed, the system waited until the change was actually changed, the system waited until the change was actually
written to disk. The file data buffers (file contents) were written to disk. The file data buffers (file contents) were
passed through the buffer cache and backed up passed through the buffer cache and backed up
@ -931,23 +931,23 @@ kern.maxfiles: 2088 -> 5000</screen>
to the disk. This includes updates to the directory itself, to the disk. This includes updates to the directory itself,
to the i-node table, and possibly to indirect blocks to the i-node table, and possibly to indirect blocks
allocated by the file. Similar considerations apply for allocated by the file. Similar considerations apply for
unrolling large hierachies (<command>tar -x</command>).</para> unrolling large hierarchies (<command>tar -x</command>).</para>
<para>The second case is asynchronous meta-data updates. This <para>The second case is asynchronous meta-data updates. This
is the default for Linux/ext2fs and is the default for Linux/ext2fs and
<command>mount -o async</command> for *BSD ufs. All <command>mount -o async</command> for *BSD ufs. All
metadata updates are simply being passed through the buffer meta-data updates are simply being passed through the buffer
cache too, that is, they will be intermixed with the updates cache too, that is, they will be intermixed with the updates
of the file content data. The advantage of this of the file content data. The advantage of this
implementation is there is no need to wait until each implementation is there is no need to wait until each
metadata update has been written to disk, so all operations meta-data update has been written to disk, so all operations
which cause huge amounts of metadata updates work much which cause huge amounts of meta-data updates work much
faster than in the synchronous case. Also, the faster than in the synchronous case. Also, the
implementation is still clear and simple, so there is a low implementation is still clear and simple, so there is a low
risk for bugs creeping into the code. The disadvantage is risk for bugs creeping into the code. The disadvantage is
that there is no guarantee at all for a consistent state of that there is no guarantee at all for a consistent state of
the filesystem. If there is a failure during an operation the filesystem. If there is a failure during an operation
that updated large amounts of metadata (like a power that updated large amounts of meta-data (like a power
failure, or someone pressing the reset button), failure, or someone pressing the reset button),
the file system the file system
will be left in an unpredictable state. There is no opportunity will be left in an unpredictable state. There is no opportunity
@ -976,18 +976,18 @@ kern.maxfiles: 2088 -> 5000</screen>
than synchronous updates. than synchronous updates.
Additionally the complexity of the implementation is fairly Additionally the complexity of the implementation is fairly
limited, so the risk of bugs being present is low. A disadvatage limited, so the risk of bugs being present is low. A disadvatage
is that all metadata are written twice (once into the is that all meta-data are written twice (once into the
logging region and once to the proper location) so for logging region and once to the proper location) so for
normal work, a performance <quote>pessimization</quote> normal work, a performance <quote>pessimization</quote>
might result. On the other hand, in case of a crash, all might result. On the other hand, in case of a crash, all
pending metadata operations can be quickly either rolled-back pending meta-data operations can be quickly either rolled-back
or completed from the logging area after the system comes or completed from the logging area after the system comes
up again, resulting in a fast filesystem startup.</para> up again, resulting in a fast filesystem startup.</para>
<para>Kirk McKusick, the developer of Berkeley FFS, <para>Kirk McKusick, the developer of Berkeley FFS,
solved this problem with Soft Updates: all pending solved this problem with Soft Updates: all pending
metadata updates are kept in memory and written out to disk meta-data updates are kept in memory and written out to disk
in a sorted sequence (<quote>ordered metadata in a sorted sequence (<quote>ordered meta-data
updates</quote>). This has the effect that, in case of updates</quote>). This has the effect that, in case of
heavy meta-data operations, later updates to an item heavy meta-data operations, later updates to an item
<quote>catch</quote> the earlier ones if the earlier ones are still in <quote>catch</quote> the earlier ones if the earlier ones are still in
@ -995,14 +995,14 @@ kern.maxfiles: 2088 -> 5000</screen>
operations on, say, a directory are generally performed in operations on, say, a directory are generally performed in
memory before the update is written to disk (the data memory before the update is written to disk (the data
blocks are sorted according to their position so blocks are sorted according to their position so
that they will not be on the disk ahead of their metadata). that they will not be on the disk ahead of their meta-data).
If the system crashes, this causes an implicit <quote>log If the system crashes, this causes an implicit <quote>log
rewind</quote>: all operations which did not find their way rewind</quote>: all operations which did not find their way
to the disk appear as if they had never happened. A to the disk appear as if they had never happened. A
consistent filesystem state is maintained that appears to consistent filesystem state is maintained that appears to
be the one of 30 to 60 seconds earlier. The be the one of 30 to 60 seconds earlier. The
algorithm used guarantees that all resources in use algorithm used guarantees that all resources in use
are marked as such in their appropriate bitmaps: blocks and i-nodes. are marked as such in their appropriate bitmaps: blocks and inodes.
After a crash, the only resource allocation error After a crash, the only resource allocation error
that occurs is that resources are that occurs is that resources are
marked as <quote>used</quote> which are actually <quote>free</quote>. marked as <quote>used</quote> which are actually <quote>free</quote>.
@ -1020,13 +1020,13 @@ kern.maxfiles: 2088 -> 5000</screen>
multiuser mode. Then, background <command>fsck</command>s multiuser mode. Then, background <command>fsck</command>s
will be scheduled for all filesystems where this is required, to free will be scheduled for all filesystems where this is required, to free
resources that may be unused. (Filesystems that do not use resources that may be unused. (Filesystems that do not use
soft updates still need the usual foreground Soft Updates still need the usual foreground
<command>fsck</command> though.)</para> <command>fsck</command> though.)</para>
<para>The advantage is that metadata operations are nearly as <para>The advantage is that meta-data operations are nearly as
fast as asynchronous updates (i. e. faster than with fast as asynchronous updates (i.e. faster than with
<emphasis>logging</emphasis>, which has to write the <emphasis>logging</emphasis>, which has to write the
metadata twice). The disadvantages are the complexity of meta-data twice). The disadvantages are the complexity of
the code (implying a higher risk for bugs in an area that the code (implying a higher risk for bugs in an area that
is highly sensitive regarding loss of user data), and a is highly sensitive regarding loss of user data), and a
higher memory consumption. Additionally there are some higher memory consumption. Additionally there are some
@ -1036,7 +1036,7 @@ kern.maxfiles: 2088 -> 5000</screen>
the standard synchronous approach would have caused some the standard synchronous approach would have caused some
zero-length files to remain after the zero-length files to remain after the
<command>fsck</command>, these files do not exist at all <command>fsck</command>, these files do not exist at all
with a soft updates filesystem because neither the metadata with a Soft Updates filesystem because neither the meta-data
nor the file contents have ever been written to disk. nor the file contents have ever been written to disk.
Disk space is not released until the updates have been Disk space is not released until the updates have been
written to disk, which may take place some time after written to disk, which may take place some time after