I have a 4-disk RAIDZ, and I reduced the time to scrub it from 80 hours to about 14 by reducing the number of snapshots, adding RAM, turning off atime, compression, and some other tweaks. This week (after replaying a large volume with dedup=on) it''s back up, way up. I replayed a 700G filesystem to get the dedup benefits, and a scrub is taking 100+ hours now. dedupratio for the pool is now around 1.7, and it was about 1.1 when my scrub took 14 hours (nothing else has really changed). arcstat.pl is showing a lot of misses, and the filesystem is seeking a lot - iostat reports 350k/sec transfer with 170 reads/sec, ouch. I''ve ordered a SSD drive to see if L2ARC will help this situation, but in general it seems like a bad trend. Agree with a previous poster that tools to estimate DDT size are important, and perhaps there are less random-access ways to scrub a deduped filesystem, if the DDT is not in core? I have several "zdb -DDD" outputs from throughout the week if anyone would like to see them. Also, is there any way to instrument "scrub" to see which parts of the filesystem it is traversing? mike