On Fri, Dec 20, 2013 at 3:55 AM, O. Hartmann
<ohart...@zedat.fu-berlin.de> wrote:
> I have a faulty pool with an ambiguous label and I tried to resolve
> that problem. ZFS is at the moment highly active copying data from
> several volumes to another.
> Operating system:
> 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r259522: Tue Dec 17 19:02:10 CET
> 2013 amd64
> In one terminal I exported the pool in question and tried to list it
> via "zpool import". But the this command sequence locks up the terminal
> for an hour up!
> In another terminal I tried to issue to command "zpool status" to watch
> the status of the pools (I have several). But this terminal ist alos
> locked up right now!
> What is wrong here? I had such an issue in 10.0-CURRENT as well. It
> seems ZFS is locking everything up and can only be brought back by a
> hard reset! What is going on? Why is zpool locking up in trying to
> display a label-scrambled pool while the zpool status is then also
> locked up, but latter is supposed to show the status of the other,
> healthy pools? This reminds me of single-threaded tools which looks up
> every operation consecutively issued after the blocking command.
> How is this to be solved?

Sounds like a deadlock.  Did the "zpool export" complete successfully?
 Did the pool become suspended at any point?  Can you get to the
kernel debugger?  Most importantly, can you reproduce it?  If you can,
you'll probably need a WITNESS enabled kernel to get any useful info.
When I find a deadlock, I usually go into the kernel debugger and
issue the following commands.  It results in about a megabyte of
output, so use screen or tmux or something to capture the output

x/s version
show msginfo
show alllocks  # You need witness for this one


> Oliver
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to