svn commit: r40102 - head/en_US.ISO8859-1/books/faq

[Eitan Adler]

Author: eadler
Date: Tue Nov 20 02:55:19 2012
New Revision: 40102
URL: http://svnweb.freebsd.org/changeset/doc/40102

Log:
  Add a section in the FAQ about ZFS
  
  Reviewed by:	peter, peterj, jpaetzel, kpneal at pobox.com,
  Reviewed by:	zbeeble at gmail.com, mcdouga9 at egr.msu.edu, many others
  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	Tue Nov 20 02:07:15 2012	(r40101)
+++ head/en_US.ISO8859-1/books/faq/book.xml	Tue Nov 20 02:55:19 2012	(r40102)
@@ -5328,6 +5328,107 @@ C:\="DOS"</programlisting>
 	</answer>
       </qandaentry>
     </qandaset>
+
+    <sect1 id="all-about-zfs">
+      <title>ZFS</title>
+
+      <qandaset>
+	<qandaentry>
+	  <question id="how-much-ram-for-zfs">
+	    <para>What is the minimum amount of RAM one should have to
+	      run ZFS?</para>
+	  </question>
+
+	  <answer>
+	    <para>A minimum of 4GB of RAM is required for comfortable
+	      usage, but individual workloads can vary widely.</para>
+	  </answer>
+	</qandaentry>
+
+	<qandaentry>
+	  <question id="what-is-zil">
+	    <para>What is the ZIL and when does it get used?</para>
+	  </question>
+
+	  <answer>
+	    <para>The <acronym>ZIL</acronym> ((<acronym>ZFS</acronym>
+	      intent log) is a write log used to implement posix write
+	      commitment semantics across crashes.  Normally writes
+	      are bundled up into transaction groups
+	      and written to disk when filled (<quote>Transaction Group
+		Commit</quote>).  However syscalls like &man.fsync.2;
+	      require a commitment to stable storage before returning.
+	      The ZIL is needed for writes that have been acknowledged
+	      as written but which are not yet on disk as part of a
+	      transaction.  The transaction groups are timestamped.
+	      In the event of a crash the last valid timestamp is
+	      found and missing data is merged in from the ZIL.</para>
+	  </answer>
+	</qandaentry>
+
+	<qandaentry>
+	  <question id="need-ssd-for-zil">
+	    <para>Do I need a SSD for ZIL?</para>
+	  </question>
+
+	  <answer>
+	    <para>By default, ZFS stores the ZIL in the pool with all
+	      the data.  If your application has a heavy write load,
+	      storing the ZIL in a separate device that has very fast
+	      synchronous, sequential write performance can improve
+	      overall system.  For other workloads, a SSD is unlikely
+	      to make much of an improvement.</para>
+	  </answer>
+	</qandaentry>
+
+	<qandaentry>
+	  <question id="what-is-l2arc">
+	    <para>What is the L2ARC?</para>
+	  </question>
+
+	  <answer>
+	    <para>The <acronym>L2ARC</acronym> is a read cache stored
+	      on a fast device such as an <acronym>SSD</acronym>.
+	      This cache is not persisent across
+	      reboots.  Note that RAM is used as the first layer
+	      of cache and the L2ARC is only needed if there is
+	      insufficient RAM.</para>
+
+	    <para>L2ARC needs space in the ARC to index it.  So,
+	      perversely, a working set that fits perfectly in the
+	      ARC will not fit perfectly any more if a L2ARC is used
+	      because part of the ARC is holding the L2ARC index,
+	      pushing part of the working set into the
+	      L2ARC which is slower than RAM.</para>
+	    </answer>
+	</qandaentry>
+
+	<qandaentry>
+	  <question id="should-enable-dedup">
+	    <para>Is enabling deduplication advisable?</para>
+	  </question>
+
+	  <answer>
+	    <para>Generally speaking, no.</para>
+
+	    <para>Deduplication takes up a significant amount
+	      of RAM and may slow down read and write
+	      disk access times.  Unless one is storing data that is
+	      very heavily duplicated (such as virtual machine images,
+	      or user backups) it is possible that deduplication will
+	      do more harm than good.  Another consideration is the
+	      inability to revert deduplication status.  If
+	      deduplication is enabled, data written, and then dedup
+	      is disabled, those blocks which were deduplicated will
+	      not be duplicated until they are next modified.</para>
+
+	    <para>Deduplication can also lead to some unexpected
+	      situations. In particular deleting files may become much
+	      slower.</para>
+	  </answer>
+	</qandaentry>
+      </qandaset>
+    </sect1>
   </chapter>
 
   <chapter id="admin">