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)
This commit is contained in:
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
|
@ -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">
|
||||
|
|
Loading…
Reference in a new issue