Date: Thu, 07 Feb 2002 16:17:14 -0500 From: Tom Rhodes <darklogik@pittgoth.com> To: Tom Hukins <tom@FreeBSD.ORG> Cc: Eric Ferguson <etf2954@rit.edu>, doc@FreeBSD.ORG Subject: Re: Doc mistake. Message-ID: <3C62EEDA.8050103@pittgoth.com> References: <20020207140922.Y50387-100000@res147b-129.rh.rit.edu> <20020207202603.A19497@eborcom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Tom Hukins wrote: Tom, may I offer the following minor nit-picks? I think it adds a slight touch of grammer. All in all, I think the rest of it was great... And you do not need to take my advice, i'm only trying to help a little ;) > ------------------------------------------------------------------------ > > Index: config/chapter.sgml > =================================================================== > RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/config/chapter.sgml,v > retrieving revision 1.37 > diff -u -r1.37 chapter.sgml > --- config/chapter.sgml 23 Jan 2002 11:59:32 -0000 1.37 > +++ config/chapter.sgml 7 Feb 2002 20:06:45 -0000 > @@ -816,17 +816,16 @@ > </indexterm> > > <para>The <varname>vfs.vmiodirenable</varname> sysctl variable > - defaults to 1 (on) and may > - be set to 0 (off) or 1 (on). This parameter controls how > + be set to either 0 (off) or 1 (on). It is 1 by default. This parameter controls how Is is 1 by default > This parameter is 1 (on) by default may sound better, opinions? > directories are cached by the system. Most directories are > - small and use but a single fragment (typically 1K) in the > - filesystem and even less (typically 512 bytes) in the buffer > + small, using just a single fragment (typically 1K) in the > + filesystem and less (typically 512 bytes) in the buffer Should a comment be after fragment and less? I think it would sound better, but I want a better opinion. > cache. However, when operating in the default mode the buffer > cache will only cache a fixed number of directories even if > you have a huge amount of memory. Turning on this sysctl > allows the buffer cache to use the VM Page Cache to cache the > - directories. The advantage is that all of memory is now > - available for caching directories. The disadvantage is that > + directories, making all the memory > + available for caching directories. However, > the minimum in-core memory used to cache a directory is the > physical page size (typically 4K) rather than 512 bytes. We > recommend turning this option on if you are running any > @@ -847,15 +846,15 @@ > <para>FreeBSD 4.3 flirted with turning off IDE write caching. > This reduced write bandwidth to IDE disks but was considered > necessary due to serious data consistency issues introduced > - by hard drive vendors. Basically the problem is that IDE > + by hard drive vendors. The problem is that IDE > drives lie about when a write completes. With IDE write > - caching turned on, IDE hard drives will not only write data > - to disk out of order, they will sometimes delay some of the > + caching turned on, IDE hard drives not only write data > + to disk out of order, but will sometimes delay writing some > blocks indefinitely when under heavy disk loads. A crash or > - power failure can result in serious filesystem corruption. > - So our default was changed to be safe. Unfortunately, the > - result was such a huge loss in performance that we caved in > - and changed the default back to on after the release. You > + power failure may cause serious filesystem corruption. > + FreeBSD's default was changed to be safe. Unfortunately, the > + result was such a huge performance loss that we > + changed write caching back to on by default after the release. You > should check the default on your system by observing the > <varname>hw.ata.wc</varname> sysctl variable. If IDE write > caching is turned off, you can turn it back on by setting > @@ -898,44 +897,44 @@ > updating the physical disk. If your system crashes you may lose more > work than otherwise. Secondly, Soft Updates delays the freeing of > filesystem blocks. If you have a filesystem (such as the root > - filesystem) which is close to full, doing a major update of it, e.g. > - <command>make installworld</command>, can run it out of space and > - cause the update to fail.</para> > + filesystem) which is almost full, doing a major update of it, e.g. > + <command>make installworld</command>, can cause the filesystem to run out of space, > + causing the update to fail.</para> Can we remove "of it" and replace this with: update, such as make installworld, could? > > <sect3> > <title>More details about Soft Updates</title> > > <indexterm><primary>Soft Updates (Details)</primary></indexterm> > > - <para>There are two classical approaches how to write metadata of > - a filesystem back to disk. (Metadata updates are updates to > - non-content data like i-nodes or directories.)</para> > + <para>There are two traditional approaches to writing a filesystem's meta-data > + 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) have > been passed through the buffer cache however, and backed up > to disk later on asynchronously. The advantage of this > - implementation is that it is operating very safely. If there is > - a failure during an update the metadata are always in a > - consistent state. A file has either been completely created > + implementation is that it operates safely. If there is > + a failure during an update, the meta-data are always in a > + consistent state. A file has either been created completely s/are/is/ comment on that, I figured is because saying it sounds more realistic ;) > or not at all. If the data blocks of a file did not find > their way out of the buffer cache onto the disk by the time > - of the crash, &man.fsck.8; is able to recognize this and to > - repair the filesystem (e. g. the file length will be set to > + of the crash, &man.fsck.8; is able to recognize this and > + repair the filesystem by setting the file length to > 0). Additionally, the implementation is clear and simple. > - The disadvantage is that metadata changes are very slow. A > - <command>rm -r</command> for instance touches all files of a > - directory sequentially, but every single of these directory > - changes (deletion of a file) will be written synchronously > + The disadvantage is that meta-data changes are slow. A s/A/an/ ? > + <command>rm -r</command> for instance touches all the files in <command>rm -r</command>, for instance, may sound better? > + directory sequentially, but each directory > + change (deletion of a file) will be written synchronously > to the disk. This includes updates to the directory itself, > - to the i-node table, and possibly to indirect blocks > + to the inode 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 are asynchronous metadata updates. This > - is e. g. the default for Linux/ext2fs or achieved by > + <para>The second case is asynchronous meta-data updates. This > + is the default for Linux/ext2fs or achieved by > <command>mount -o async</command> for *BSD ufs. All > metadata updates are simply being passed through the buffer > cache too, that is, they will be intermixed with the updates > @@ -948,101 +947,101 @@ > 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 chance > + will be left in an unpredictable state. There is no opportunity > 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 > + been written to the disk while the updates of the inode > table or the associated directory were not. It is actually > impossible to implement a <command>fsck</command> which is > able to clean up the resulting chaos (because the necessary > - information is just not available on the disk). If the > + information is not available on the disk). If the > filesystem has been damaged beyond repair, the only choice > is to <command>newfs</command> it and restore it from backup. > </para> > > - <para>The usual solution for this problem was to implement a > - <emphasis>dirty region logging</emphasis> (sometimes also > - referred to as <emphasis>journalling</emphasis>, albeit that > - term has not been used consistently and occasionally applied > - to other forms of transaction logging as well). Metadata > - updates are still written out synchronously, but only into a > - small region of the disk. Later on they will be distributed > - from there to their proper location. Because the logging > - area is only a small, contiguous region on the disk, there > + <para>The usual solution for this problem was to implement > + <emphasis>dirty region logging</emphasis>, which is also > + referred to as <emphasis>journalling</emphasis>, although that > + term is not used consistently and is occasionally applied > + to other forms of transaction logging as well. Meta-data > + updates are still written synchronously, but only into a > + small region of the disk. Later on they will be moved > + to their proper location. Because the logging > + area is a small, contiguous region on the disk, there > are no long distances for the disk heads to move, even > - during heavy operations, so these operations are accelerated > - quite a bit compared to the classical synchronous updates. > + during heavy operations, so these operations are quicker > + than synchronous updates. > Additionally the complexity of the implementation is fairly > - limited and thus the risk for bugs still low. A disadvatage > - is that all metadata are written twice (once into the > + limited, so the risk of bugs being present is low. A disadvatage > + 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>Now, Kirk McKusick's (the developer of Berkeley FFS) > - solution to the problem are Soft Updates: all pending > - metadata updates are kept in memory and written out to disk > - in a sorted sequence (<quote>ordered metadata > + <para>Kirk McKusick (the developer of Berkeley FFS) Maybe this can be: Kirk McKusick, the developer of the Berkely FFS, > + solved this problem with Soft Updates: all pending > + 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 metadata operations, later updates of a certain item > - <quote>catch</quote> the earlier ones if those are still in > + heavy meta-data operations, later updates to an item > + <quote>catch</quote> the earlier ones if the earlier ones are still in > memory and have not already been written to disk. So all > - operations on, say, a directory are generally done still in > + operations on, say, a directory are generally done in > memory before the update is written to disk (the data > - blocks are sorted to their according position as well so > + blocks are sorted according to their position so > that they will not be on the disk ahead of their metadata). > - In case of a crash 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 > to the disk appear as if they had never happened. A > consistent filesystem state is maintained that appears to > - be the one of 30--60 seconds earlier. The > - algorithm used guarantees that all actually used resources > - are marked as such in their appropriate bitmaps: blocks and i-nodes. > + be the one of 30 to 60 seconds earlier. The > + algorithm used guarantees that all used resources > + are marked as such in their appropriate bitmaps: blocks and inodes. > After a crash, the only resource allocation error > - that occur are that resources are > - marked as <quote>used</quote> which actually are <quote>free</quote>. > - &man.fsck.8; then recognizes this situation, > - and free up those no longer used resources. It is safe to > - ignore the dirty state of the filesystem after a crash, by > + that occurs is that resources are > + marked as <quote>used</quote> which are actually <quote>free</quote>. > + &man.fsck.8; recognizes this situation, > + and frees the resources that are no longer used. It is safe to > + ignore the dirty state of the filesystem after a crash by > forcibly mounting it with <command>mount -f</command>. In > - order to free up possibly unused resources, &man.fsck.8; > + order to free up resources that may be unused, &man.fsck.8; > needs to be run at a later time. This is the idea behind > the <emphasis>background fsck</emphasis>: at system startup > - 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 > + time, only a <emphasis>snapshot</emphasis> of the > + filesystem is recorded, the <command>fsck</command> can be > + run later on. All filesystems can then be mounted > + <quote>dirty</quote>, so the system startup proceeds in > 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 > + 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 > <command>fsck</command> though.)</para> > > - <para>The advantage is that metadata operations are nearly as > - fast as asynchronous updates (i. e. faster than with > + <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 > 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 > - <quote>idiosyncrasies</quote> one has to get used to. > + idiosyncrasies one has to get used to. > After a crash, the state of the filesystem appears to be > - somewhat <quote>older</quote>; e. g. in situations where > + somewhat <quote>older</quote>. In situations where > 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. > - After a <command>rm</command>, the released disk space is > - 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 > + Disk space is not released until the updates have been > + written to disk, which may take place some time after > + running <command>rm</command> . This may cause problems > + when installing large amounts of data on a filesystem > that does not have enough free space to hold all the files > twice.</para> > </sect3> > -- Tom (Darklogik) Rhodes www.Pittgoth.com Gothic Liberation Front www.FreeBSD.org The Power To Serve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C62EEDA.8050103>