SSD recommendations for ZFS cache/log

Zaphod Beeblebrox zbeeble at gmail.com
Fri Nov 16 05:41:36 UTC 2012


On Thu, Nov 15, 2012 at 11:40 PM,  <kpneal at pobox.com> wrote:
>> +       <answer>
>> +         <para>The answer very much depends on the expected workload.
>> +           Deduplication takes up a signifigent amount of RAM and CPU
>> +           time 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 likely that deduplication will do more harm
>> +           than good.  Another consideration is the inability to
>
> I advise against advice that is this firm. The statement that it will "do
> more harm than good" really should be omitted. And I'm not sure it is
> fair to say it takes a bunch of CPU. Lots of memory, yes, but lots of
> CPU isn't so clear.

I experimented by enabling DEDUP on a RAID-Z1 pool containing 4x 2T
green drives.  The system had 8G of RAM and was otherwise quiet.  I
copied a dataset of about 1T of random stuff onto the array and then
copied the same set of data onto the array a second time. The end
result is a dedup ration of almost 2.0 and only around 1T of disk
used.

As I recall (and it's been 6-ish months since I did this), the 2nd
write became largely CPU bound with little disk activity.  As far as I
could tell, the dedup table never thrashed on the disk ... and that
most of the disk activity seemed to be creating the directory tree or
reading the disk to do the verify step of dedup.

The CPU is modest... a 2.6 Ghz Core-2-duo --- and I don't recall if it
busied both cores or just one.


More information about the freebsd-fs mailing list