On 02/11/10 08:15, taemun wrote:
Can anyone comment about whether the on-boot "Reading ZFS confi" is
any slower/better/whatever than deleting zpool.cache, rebooting and
manually importing?
I've been waiting more than 30 hours for this system to come up. There
is a pool with 13TB of data attached. The system locked up whilst
destroying a 934GB dedup'd dataset, and I was forced to reboot it. I
can hear hard drive activity presently - ie its doing
<b>something</b>, but am really hoping there is a better way :)
Thanks
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
I think that this is a consequence of 6924390.-
<http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6924390> ZFS
destroy on de-duped dataset locks all I/O
This bug is closed as a dup of another bug which is not readable from
the opensolaris site, (I'm not clear what makes some bugs readable and
some not).
While trying to reproduce 6924390 (or its equivalent) yesterday, my
system hung as yours did, and when I rebooted, it hung at "Reading ZFS
config".
Someone who knows more about the root cause of this situation (i.e., the
bug named above) might be able tell you what's going on and how to
recover (it might be that what's going on is that the destroy has
resumed and you have to wait for it to complete, which I think it will,
but it might take a long time).
Lori
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
