Just wanted to post a bit of closure to this thread quick... Most of the "import taking too long threads" I've found on the list tend to fade out without any definitive answer as to what went wrong. I needed something a bit more concrete to make me happy.
After zfs send'ing everything to a fresh pool, I destroyed the problematic pool and re-created it without dedup. I also recreated the original conditions of minimal RAM (only 4GB with half of that eaten by xVM), and created a new 2TB zvol. I re-ran my original experiment trying to get lofi encryption setup on top of the zvol (which worked, but proved far too slow to be any use, alas...), then zfs destroy'd the zvol. Destroy was close enough to instantaneous on the same hardware as the original problem. It was definitely the dedup (made far more acute by memory starvation) that caused the zfs destroy and subsequent re-import to take forever. So for the sake of keyword searches: zfs dedup (or dedupe) makes zfs destroy of large zvol take a long time, possibly causing kernel panic and/or system lockup on systems with low memory (2GB - 4GB confirmed, possibly higher). zfs import on subsequent reboot also takes a long time, but will eventually finish given adequate RAM. Disabling vXM and returning RAM from Xen to the dom0 may improve the speed and/or prevent system crashes before completion. Thanks again, all! -Zac -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
