Date: Tue, 20 Nov 2012 02:55:19 +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: r40102 - head/en_US.ISO8859-1/books/faq Message-ID: <201211200255.qAK2tJg5005739@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
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@pobox.com, Reviewed by: zbeeble@gmail.com, mcdouga9@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">
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201211200255.qAK2tJg5005739>