<div dir="ltr"><div>Hi,<br></div>Thanks for your feedback ! It does not hang in my case, but maybe it is related anyway.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 28 April 2014 16:22, Youzhong Yang <span dir="ltr"><<a href="mailto:youzhong@gmail.com" target="_blank">youzhong@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">This could be the following issue:<div><br></div><div><a href="https://www.illumos.org/issues/4730" target="_blank">https://www.illumos.org/issues/4730</a><br>
</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">
On Mon, Apr 28, 2014 at 9:17 AM, Alex <span dir="ltr"><<a href="mailto:alex.ranskis@gmail.com" target="_blank">alex.ranskis@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5">
<div dir="ltr"><div><div><div><div><div><div><div>Hello,<br><br></div>I'm trying to understand this behavior, which I see on servers connected to an external disk enclosure. (I cannot reproduce it on a simple 1 disk VM)<br>
<br># kstat -c taskq | grep metaslab_group_tasksq| wc -l<br>1112<br><br># zpool import >/dev/null<br><br># kstat -c taskq | grep metaslab_group_tasksq| wc -l<br>1160<br><br><br>we are accumulating 'metaslab_group_taskqs'<br>
<br>module: unix instance: 513 <br>name: metaslab_group_tasksq class: taskq<br> crtime 842173.739164514<br> executed 0<br>
maxtasks 0<br> nactive 0<br> nalloc 0<br> pid 0<br> priority 60<br>
snaptime 842774.7092530ok 06<br> tasks 0<br> threads 3<br> totaltime 0<br><br></div><div><br></div>
The "zpool import" command itself runs fine. I get the same behavior whether there are pools to import or not.<br><br></div>but kernel threads are piling up, for each CV there are 3 threads :<br>> ffffff05844fe080::wchaninfo -v<br>
ADDR TYPE NWAITERS THREAD PROC<br>ffffff05844fe080 cond 3: ffffff0021c58c40 sched<br> ffffff0021c5ec40 sched<br> ffffff0021c64c40 sched<br>
<br></div>and they're all blocking, with a similar stack :<br>> ffffff0021c58c40::findstack -v<br>stack pointer for thread ffffff0021c58c40: ffffff0021c58a80<br>[ ffffff0021c58a80 _resume_from_idle+0xf4() ]<br> ffffff0021c58ab0 swtch+0x141()<br>
ffffff0021c58af0 cv_wait+0x70(ffffff05844fe080, ffffff05844fe070)<br> ffffff0021c58b60 taskq_thread_wait+0xbe(ffffff05844fe050, ffffff05844fe070, ffffff05844fe080, ffffff0021c58bc0, ffffffffffffffff)<br> ffffff0021c58c20 taskq_thread+0x37c(ffffff05844fe050)<br>
ffffff0021c58c30 thread_start+8()<br><br><br></div><div>the taskq seems to be created by a call to metaslab_group_create(), here :<br> zfs`vdev_alloc+0x54a<br> zfs`spa_config_parse+0x48<br> zfs`spa_config_parse+0xda<br>
zfs`spa_config_valid+0x78<br> zfs`spa_load_impl+0xa81<br> zfs`spa_load+0x14e<br> zfs`spa_tryimport+0xaa<br> zfs`zfs_ioc_pool_tryimport+0x51<br> zfs`zfsdev_ioctl+0x4a7<br>
genunix`cdev_ioctl+0x39<br> specfs`spec_ioctl+0x60<br> genunix`fop_ioctl+0x55<br> genunix`ioctl+0x9b<br> unix`sys_syscall32+0xff<br><br></div><div><br></div>
I'm out of my depth here, any pointer to investigate further would be much appreciated !<br><br></div>cheers,<br></div>alex<br></div>
<br></div></div>_______________________________________________<br>
OmniOS-discuss mailing list<br>
<a href="mailto:OmniOS-discuss@lists.omniti.com" target="_blank">OmniOS-discuss@lists.omniti.com</a><br>
<a href="http://lists.omniti.com/mailman/listinfo/omnios-discuss" target="_blank">http://lists.omniti.com/mailman/listinfo/omnios-discuss</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>