Date: Sat, 1 Dec 2012 17:00:17 +0000 (UTC) From: Eitan Adler <eadler@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r40228 - head/en_US.ISO8859-1/books/faq Message-ID: <201212011700.qB1H0H3v052074@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: eadler Date: Sat Dec 1 17:00:17 2012 New Revision: 40228 URL: http://svnweb.freebsd.org/changeset/doc/40228 Log: Update and clarify the FAQ on soft-updates. Noted by: -stable mailing list Approved by: bcr (mentor) Modified: head/en_US.ISO8859-1/books/faq/book.xml Modified: head/en_US.ISO8859-1/books/faq/book.xml ============================================================================== --- head/en_US.ISO8859-1/books/faq/book.xml Sat Dec 1 15:51:31 2012 (r40227) +++ head/en_US.ISO8859-1/books/faq/book.xml Sat Dec 1 17:00:17 2012 (r40228) @@ -4489,24 +4489,25 @@ kern.sched.name: ULE</screen> <question id="safe-softupdates"> <para>Which partitions can safely use Soft Updates? I have heard that Soft Updates on <filename class="directory">/</filename> can cause - problems.</para> + problems. What about Journaled Soft Updates?</para> </question> <answer> <para>Short answer: you can usually use Soft Updates safely on all partitions.</para> - <para>Long answer: There used to be some concern over using - Soft Updates on the root partition. Soft Updates has two - characteristics that caused this. First, a Soft Updates + <para>Long answer: Soft Updates has two + characteristics that may be undesirable on certain + paritions. First, a Soft Updates partition has a small chance of losing data during a system crash. (The partition will not be corrupted; the data will - simply be lost.) Also, Soft Updates can cause temporary + simply be lost.) Second, Soft Updates can cause temporary space shortages.</para> <para>When using Soft Updates, the kernel can take up to - thirty seconds to actually write changes to the physical - disk. If you delete a large file, the file still resides on + thirty seconds to write changes to the physical + disk. When a large file is deleted the file still + resides on disk until the kernel actually performs the deletion. This can cause a very simple race condition. Suppose you delete one large file and immediately create another large file. @@ -4522,20 +4523,14 @@ kern.sched.name: ULE</screen> <para>If a system should crash after the kernel accepts a chunk of data for writing to disk, but before that data is - actually written out, data could be lost or corrupted. This - risk is extremely small, but generally manageable. Use of - IDE write caching greatly increases this risk; it is - strongly recommended that you disable IDE write caching when - using Soft Updates.</para> + actually written out, data could be lost. This + risk is extremely small, but generally manageable.</para> <para>These issues affect all partitions using Soft Updates. So, what does this mean for the root partition?</para> <para>Vital information on the root partition changes very - rarely. Files such as - <filename>/boot/kernel/kernel</filename> and the contents of - <filename class="directory">/etc</filename> only change during system - maintenance, or when users change their passwords. If the + rarely. If the system crashed during the thirty-second window after such a change is made, it is possible that data could be lost. This risk is negligible for most applications, but you @@ -4551,6 +4546,10 @@ kern.sched.name: ULE</screen> problems. Symlinking <filename class="directory">/tmp</filename> to <filename class="directory">/var/tmp</filename> will solve this problem.</para> + + <para>Finally, &man.dump.8; does not work in live mode (-L) + on a filesystem, with Journaled Soft Updates + (<acronym>SU+J</acronym>).</para> </answer> </qandaentry>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201212011700.qB1H0H3v052074>