> 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, and #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 zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
