Greetings, snv_79a AMD 64x2 in 64 bit kernel mode. I''m in the middle of migrating a large zfs set from a pair of 1TB mirrors to a 1.3TB RAIDz. I decided to use zfs send | zfs receive, so the first order of business was to snap the entire source filesystem. # zfs snapshot -r store at now What happened was expected, the source drives flashed and wiggled :) What happened next was not, the destination drives (or maybe the boot drive, as they share one disk activity light) began flashing and wiggling, and have been doing so for 12 hours how. iostat shows no activity to speak of, and no transfers at all on any of the disks. ditto for zpool iostat. all zfs commands hang, and the lack of output from truss''ing the pids indicate they are stuck in the kernel. Heck, I can''t even reboot, as that hangs. So what I was wondering whether there exists a dtrace recipe or some such that I can use to figure out where this is hung in the kernel. Cheers! -sam -- This message posted from opensolaris.org
> snv_79a > AMD 64x2 in 64 bit kernel mode.[...]> all zfs commands hang, and the lack of output from truss''ing the pids > indicate they are stuck in the kernel. Heck, I can''t even reboot, as that > hangs. > > So what I was wondering whether there exists a dtrace recipe or some > such that I can use to figure out where this is hung in the kernel.What prstat says ? If the cpus are under load, this might pinpoint some frequently visited stack. $ dtrace -n ''profile-1000Hz{ @[stack()]=count() }'' and breaking it after while. You will get long listing, so you may want to redirect to file. Recently I saw zfs issue, where every zfs command hanged. It was caused by full zfs volume. This dtrace script showed that kernel is spinning in some loop in zfs module. HTH -- Vlad -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 193 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20080416/be2dd2ca/attachment.bin>