2012-08-01 17:55, Sašo Kiselkov пишет:
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.
Unfortunately, as of current implementations, L2ARC starts up cold.
That is, upon every import of the pool the L2ARC is empty, and the
DDT (as in the example above) would have to migrate into the cache
via read-from-rust to RAM ARC and expiration from the ARC. Getting
it to be hot and fast again takes some time, and chances are that
some blocks of userdata might be more popular than a DDT block and
would push it out of L2ARC as well...
//Jim
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
