On Aug 11, 2010, at 9:46 PM, Ville Ojamo wrote: > I am having a similar issue at the moment.. 3 GB RAM under ESXi, but dedup > for this zvol (1.2 T) was turned off and only 300 G was used. The pool does > contain other datasets with dedup turned on but are small enough so I'm not > hitting the memory limits (been there, tried that, never again without maxing > out the RAM + SSD). > > Tried to destroy the zvol, waited for a long time, and due to some unexpected > environmental problems needed to pull the plug on the box quickly to save it. > Now the boot is at "Reading ZFS config: *" since a few days, but I have time > to wait. ESXi monitoring confirms CPU activity but very little I/O. > > My point, this particular zvol did not have deduplication turned on but it > seems I am still hitting the same problem. > > snv_134 > > BTW this is a PoC box with nothing too important on it and I have some spare > time, so if I can help somehow, for example with kernel debugging let me know.
There are several fixes since b134, such as CR6948890 snapshot deletion can induce pathologically long spa_sync() times http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6948890 You might be hitting this, also. I know we've integrated this fix into the later Nexenta releases. -- richard -- Richard Elling rich...@nexenta.com +1-760-896-4422 Enterprise class storage for everyone www.nexenta.com _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
