On 01 August, 2012 - opensolarisisdeadlongliveopensolaris sent me these 1,8K bytes:
> > 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." "Adaptive Replacement Cache", right. > 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 /Tomas -- Tomas Forsman, st...@acc.umu.se, http://www.acc.umu.se/~stric/ |- Student at Computing Science, University of Umeå `- Sysadmin at {cs,acc}.umu.se _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
