> From: Sašo Kiselkov [mailto:skiselkov...@gmail.com]
> Sent: Wednesday, August 01, 2012 9:56 AM
> On 08/01/2012 03:35 PM, opensolarisisdeadlongliveopensolaris wrote:
> >> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> >> boun...@opensolaris.org] On Behalf Of Jim Klimov
> >>
> >> Availability of the DDT is IMHO crucial to a deduped pool, so
> >> I won't be surprised to see it forced to triple copies.
> >
> > IMHO, the more important thing for dedup moving forward is to create an
> option to dedicate a fast device (SSD or whatever) to the DDT.  So all those
> little random IO operations never hit the rusty side of the pool.
> That's something you can already do with an L2ARC. In the future I plan
> on investigating implementing a set of more fine-grained ARC and L2ARC
> policy tuning parameters that would give more control into the hands of
> admins over how the ARC/L2ARC cache is used.

L2ARC is a read cache.  Hence the "R" and "C" in "L2ARC."
This means two major things:
#1  Writes don't benefit, 
#2  There's no way to load the whole DDT into the cache anyway.  So you're 
guaranteed to have performance degradation with the dedup.
zfs-discuss mailing list

Reply via email to