On Sat, 14 Feb 2009 15:40:04 -0600 (CST) David Dyer-Bennet <d...@dd-b.net> wrote:
> > On Sat, February 14, 2009 13:04, Blake wrote: > > I think you can kill the destroy command process using traditional > > methods. > > kill and kill -9 failed. In fact, rebooting failed; I had to use a > hard reset (it shut down most of the way, but then got stuck). > > > Perhaps your slowness issue is because the pool is an older format. > > I've not had these problems since upgrading to the zfs version that > > comes default with 2008.11 > > We can hope. In case that's the cause, I upgraded the pool format > (after considering whether I'd be needing to access it with older > software; hope I was right :-)). > > The pool did import and scrub cleanly, anyway. That's hopeful. Also > this particular pool is a scratch pool at the moment, so I'm not > risking losing data, only risking losing confidence in ZFS. It's > also a USB external disk. Hi David, if this happens to you again, you could help get more data on the problem by getting a crash dump, either forced or via reboot or (if you have a dedicated dump device, via savecore: (dedicated dump dev, ) # savecore -L /var/crash/`uname -n` or # reboot -dq (forced, 64bit mode) # echo "0>rip"|mdb -kw (forced, 32bit mode) # echo "0>eip"|mdb -kw Try the command line options first, only use the mdb kick in the guts if the other two fail. Once you've got the core, you could post the output of ::status $C when run over the core with mdb -k. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
