os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Add a section in the FAQ about ZFS

Browse source 
Reviewed by:	peter, peterj, jpaetzel, kpneal@pobox.com,
Reviewed by:	zbeeble@gmail.com, mcdouga9@egr.msu.edu, many others
Approved by:	bcr (mentor)
This commit is contained in:
Eitan Adler 2012-11-20 02:55:19 +00:00
parent 3ff6bac35d
commit 9aa841ff06
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=40102
1 changed files with 101 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

101
en_US.ISO8859-1/books/faq/book.xml
View file

@ -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">