SSD recommendations for ZFS cache/log

[Adam McDougall]

On 11/16/12 00:41, Zaphod Beeblebrox wrote:
> 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.
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
>

Now try deleting some data and the fun begins :)