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

36
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>
<para>There are two traditional approaches to writing a filesystem's meta-data
back to disk. (Metadata updates are updates to
non-content data like i-nodes or directories.)</para>
back to disk. (Meta-data updates are updates to
non-content data like inodes or directories.)</para>
<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
written to disk. The file data buffers (file contents) were
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 i-node table, and possibly to indirect blocks
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
is the default for Linux/ext2fs and
<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
of the file content data. The advantage of this
implementation is there is no need to wait until each
metadata update has been written to disk, so all operations
which cause huge amounts of metadata updates work much
meta-data update has been written to disk, so all operations
which cause huge amounts of meta-data updates work much
faster than in the synchronous case. Also, the
implementation is still clear and simple, so there is a low
risk for bugs creeping into the code. The disadvantage is
that there is no guarantee at all for a consistent state of
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),
the file system
will be left in an unpredictable state. There is no opportunity
@ -976,18 +976,18 @@ kern.maxfiles: 2088 -> 5000</screen>
than synchronous updates.
Additionally the complexity of the implementation is fairly
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
normal work, a performance <quote>pessimization</quote>
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
up again, resulting in a fast filesystem startup.</para>
<para>Kirk McKusick, the developer of Berkeley FFS,
solved this problem with Soft Updates: all pending
metadata updates are kept in memory and written out to disk
in a sorted sequence (<quote>ordered metadata
meta-data updates are kept in memory and written out to disk
in a sorted sequence (<quote>ordered meta-data
updates</quote>). This has the effect that, in case of
heavy meta-data operations, later updates to an item
<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
memory before the update is written to disk (the data
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
rewind</quote>: all operations which did not find their way
to the disk appear as if they had never happened. A
consistent filesystem state is maintained that appears to
be the one of 30 to 60 seconds earlier. The
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
that occurs is that resources are
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
will be scheduled for all filesystems where this is required, to free
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>
<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
<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
is highly sensitive regarding loss of user data), and a
higher memory consumption. Additionally there are some
@ -1036,7 +1036,7 @@ kern.maxfiles: 2088 -> 5000</screen>
the standard synchronous approach would have caused some
zero-length files to remain after the
<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.
Disk space is not released until the updates have been
written to disk, which may take place some time after