On Mon, Apr 11, 2011 at 10:55 AM, Matt Harrison <iwasinnamuk...@genestate.com> wrote: > It did finish eventually, not sure how long it took in the end. Things are > looking good again :)
If you want to continue using dedup, you should invest in (a lot) more memory. The amount of memory required depends on the size of your pool and the type of data that you're storing. Data that large blocks will use less memory. I suspect that the minimum memory for most moderately sized pools is over 16GB. There has been a lot of discussion regarding how much memory each dedup'd block requires, and I think it was about 250-270 bytes per block. 1TB of data (at max block size and no duplicate data) will require about 2GB of memory to run effectively. (This seems high to me, hopefully someone else can confirm.) This is memory that is available to the ARC, above and beyond what is being used by the system and applications. Of course, using all your ARC to hold dedup data won't help much either, as either cacheable data or dedup info will be evicted rather quickly. Forcing the system to read dedup tables from the pool is slow, since it's a lot of random reads. All I know is that I have 8GB in my home system, and it is not enough to work with the 8TB pool that I have. Adding a fast SSD as L2ARC can help reduce the memory requirements somewhat by keeping dedup data more easily accessible. (And make sure that your L2ARC device is large enough. I fried a 30GB OCV Vertex in just a few months of use, I suspect from the constant writes.) -B -- Brandon High : bh...@freaks.com _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
