And pstack won't give stack on bootadm process:
devu...@zfs05:/var/crash/zfs05# pstack 23870
23870: /sbin/bootadm -a update_all
devu...@zfs05:/var/crash/zfs05# pstack -F 23870
23870: /sbin/bootadm -a update_all
devu...@zfs05:/var/crash/zfs05# kill -9 23870
devu...@zfs05:/var/crash/zfs05# kill -9
Some more info - the system won't shutdown, issuing shutdown -g0 -i5 just sits
there doing nothing.
Then i tried to find locks on the savecore i took, - mdb crashes:
mdb -k ./unix.1 ./vmcore.1
mdb: failed to read panicbuf and panic_reg -- current register set will be
unavailable
Loading modules
Ok, sorry for spamming - got some more info from mdb -k
devu...@zfs05:/var/crash/zfs05# mdb -k unix.0 vmcore.0
mdb: failed to read panicbuf and panic_reg -- current register set will be
unavailable
Loading modules: [ unix genunix specfs dtrace cpu.generic uppc pcplusmp
scsi_vhci zfs sd ip hook n
Forgot to mention - 1. this system was installed as 2008.11, so it should have
no upgrade issues.
2. Not sure how to do the mdb -k on the dump, the only thing it produced is the
following:
> ::status
debugging live kernel (64-bit) on zfs05
operating system: 5.11 snv_101b (i86pc)
> $C
>
--
This m
We have just got a hang like this.
Here's the output of ps -ef | grep zfs:
root 425 7 0 Jun 17 console 0:00 /usr/lib/saf/ttymon -g -d
/dev/console -l console -m ldterm,ttcompat -h -p zfs0
root 22879 22876 0 18:18:37 ? 0:01 /usr/sbin/zfs rollback -r
tank/aa
root
Thanks, I've filed your message where I can easily get at it even if I'm
having trouble with the server. I'm afraid I'd rather I didn't get the
chance to use it, but if something weird does go on, I'm happy to have the
procedure to capture information that might help get it identified and
fixed.
On Sat, 14 Feb 2009 15:40:04 -0600 (CST)
David Dyer-Bennet 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 d
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 becaus
I think you can kill the destroy command process using traditional methods.
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
On Fri, Feb 13, 2009 at 4:14 PM, David Dyer-Bennet wrote
This shouldn't be taking anywhere *near* half an hour. The snapshots
differ trivially, by one or two files and less than 10k of data (they're
test results from working on my backup script). But so far, it's still
sitting there after more than half an hour.
local...@fsfs:~/src/bup2# zfs destroy r
10 matches
Mail list logo
