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

Expand a couple of contractions and remove a stray space in Joerg's

Browse source 
wonderful explanation of Soft Updates.

Reviewed by:	joerg
Approved by:	joerg
This commit is contained in:
Peter Pentchev 2002-01-22 12:18:42 +00:00
parent e3df3bbb8e
commit 0f24b33495
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=11796
1 changed files with 6 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -940,18 +940,18 @@ kern.maxfiles: 2088 -> 5000</screen>
metadata 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's 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
which cause huge amounts of metadata updates work much
faster than in the synchronous case. Also, the
implementation is still clear and simple, so there's a low
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
failure, or someone pressing the reset button),
the file system
will be left in an unpredictable state. There's no chance
will be left in an unpredictable state. There is no chance
to examine the state of the file system when the system
comes up again; the data blocks of a file could already have
been written to the disk while the updates of the i-node
@ -996,7 +996,7 @@ kern.maxfiles: 2088 -> 5000</screen>
operations on, say, a directory are generally done still in
memory before the update is written to disk (the data
blocks are sorted to their according position as well so
that they won't be on the disk ahead of their metadata).
that they will not be on the disk ahead of their metadata).
In case of a crash 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
@ -1017,7 +1017,7 @@ kern.maxfiles: 2088 -> 5000</screen>
time, only a <emphasis>snapshot</emphasis> from the
filesystem is recorded, that <command>fsck</command> can be
run against later on. All filesystems can then be mounted
<quote> dirty</quote>, and system startup proceeds to
<quote>dirty</quote>, and system startup proceeds to
multiuser mode. Then, background <command>fsck</command>s
will be scheduled for all filesystems that need it, to free
up possibly unused resources. (Filesystems that do not use
@ -1043,7 +1043,7 @@ kern.maxfiles: 2088 -> 5000</screen>
not instantly available but only after the updates have
written to disk. This can in particular cause problems
when installing large amounts of data into a filesystem
that doesn't have enough free space to hold all the files
that does not have enough free space to hold all the files
twice.</para>
</sect3>
</sect2>