From c8817a56e8edc53a62e852b7f71a8d0166929149 Mon Sep 17 00:00:00 2001 From: Tom Hukins Date: Thu, 28 Feb 2002 22:27:15 +0000 Subject: [PATCH] Fix the following typos: metadata -> meta-data i-nodes -> inodes hierachies -> hierarchies i. e. -> i.e. soft updates -> Soft Updates --- .../books/handbook/config/chapter.sgml | 38 +++++++++---------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/en_US.ISO8859-1/books/handbook/config/chapter.sgml b/en_US.ISO8859-1/books/handbook/config/chapter.sgml index c7887ae885..5328ce5b4f 100644 --- a/en_US.ISO8859-1/books/handbook/config/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/config/chapter.sgml @@ -907,11 +907,11 @@ kern.maxfiles: 2088 -> 5000 Soft Updates (Details) 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.) + back to disk. (Meta-data updates are updates to + non-content data like inodes or directories.) 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 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 (tar -x). + unrolling large hierarchies (tar -x). The second case is asynchronous meta-data updates. This is the default for Linux/ext2fs and mount -o async 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 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 pessimization 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. 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 (ordered metadata + meta-data updates are kept in memory and written out to disk + in a sorted sequence (ordered meta-data updates). This has the effect that, in case of heavy meta-data operations, later updates to an item catch the earlier ones if the earlier ones are still in @@ -995,14 +995,14 @@ kern.maxfiles: 2088 -> 5000 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 log rewind: 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 used which are actually free. @@ -1020,13 +1020,13 @@ kern.maxfiles: 2088 -> 5000 multiuser mode. Then, background fscks 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 fsck though.) - The advantage is that metadata operations are nearly as - fast as asynchronous updates (i. e. faster than with + The advantage is that meta-data operations are nearly as + fast as asynchronous updates (i.e. faster than with logging, 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 the standard synchronous approach would have caused some zero-length files to remain after the fsck, 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