On Sun, Jun 13, 2010 at 6:58 PM, Matthew Anderson <matth...@ihostsolutions.com.au> wrote: > The problem didn’t seem to occur with only a small amount of data on the LUN > (<50GB) and happened more frequently as the LUN filled up. I’ve since moved > all data to non-dedup LUN’s and I haven’t seen a dropout for over a month.
How much memory do you have, and how big is the DDT? You can get the DDT size with 'zdb -DD'. The total count is the sum of duplicate and unique entries. Each entry uses ~ 250 bytes per entry, so the count divided by 4 is a (very rough) estimate of the memory size of the DDT in kilobytes. The most likely case is that you don't have enough memory to hold the entire dedup table in the ARC. When this happens, the host has to read entries from the main pool, which is slow. If you want to continue running with dedup, adding a L2ARC may help since the DDT can be held in the faster cache. Disabling dedup for the dataset will give you good write performance too. Be aware that destroying snapshots from this dataset (or destroying the dataset itself) is likely to create dropouts as well, since the DDT needs to be scanned to see if a block can be dereferenced. Again, adding L2ARC may help. -B -- Brandon High : bh...@freaks.com _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
