I've previously posted about some lockups I've experienced with ZFS. There were two suspected causes at the time: one was deduplication, and one was the 2009.06 code we were running.
I upgraded to OpenIndiana 147 (initially without upgrading the zpool and zfs disk versions). The lockups reduced in frequency but still occurred. I've since upgraded the zpool and zfs versions and we'll see what happens. Dedup was the more likely causes and so we turned it off and recreated all the iscsi LUNS that were being exported so as to eliminate the deduplicated data. That almost entirely eliminated the lockups. Having said all that- I have two questions: When I query for the dedupratio, I still a value of 2.37x -------------------------------------------------- r...@nas:~# zpool get dedupratio pool0 NAME PROPERTY VALUE SOURCE pool0 dedupratio 2.37x - -------------------------------------------------- Considering the fact that all of the iscsi LUNS that were created when dedup was on were subsequently deleted and recreated with dedup disabled- I don't understand why the value is still 2.37x. It should be near zero (There are probably a couple of small luns that were not removed but they are rarely used). Am I misinterpreting the meaning of this number? Second question: The most recent pool lockup was caused when a zpool scrub was kicked off. Initially we see 0 values for the write bandwidth in a zpool iostat and average numbers for the read. After a few minutes we see the read numbers jump to several hundred megs/second and the write performance fluctuate between 0 and a few kilobytes/second. Anyone else see this behavior and can provide some insight? -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
