From 0f24b33495c7bc4651fb9db947aed4bfca3a9ad6 Mon Sep 17 00:00:00 2001 From: Peter Pentchev Date: Tue, 22 Jan 2002 12:18:42 +0000 Subject: [PATCH] Expand a couple of contractions and remove a stray space in Joerg's wonderful explanation of Soft Updates. Reviewed by: joerg Approved by: joerg --- en_US.ISO8859-1/books/handbook/config/chapter.sgml | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/en_US.ISO8859-1/books/handbook/config/chapter.sgml b/en_US.ISO8859-1/books/handbook/config/chapter.sgml index 08f9463f1c..ae66aae91a 100644 --- a/en_US.ISO8859-1/books/handbook/config/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/config/chapter.sgml @@ -940,18 +940,18 @@ kern.maxfiles: 2088 -> 5000 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 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 log rewind: 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 time, only a snapshot from the filesystem is recorded, that fsck can be run against later on. All filesystems can then be mounted - dirty, and system startup proceeds to + dirty, and system startup proceeds to multiuser mode. Then, background fscks 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 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.