Discussion:
Created taskq not destroyed in metaslab.c
Long Ma
2014-03-14 22:18:23 UTC
Permalink
Hi everyone,

I noticed something odd in current metaslab code. In the metaslab.c file,
the "metaslab_group_tasksq" is created in the metaslab_group_create
function but it is not destroyed in the metaslab_group_destroy function.

I first noticed this problem by doing zpool import. Threadlist shows that
there is an increasing amount of metaslab_group_tasksq being created but
never destroyed.
Repeated use of zpool import will eventually cause the system to hit the
max thread limit.

This is the changeset at which the create_taskq is added into the
metaslab.c:
https://github.com/illumos/illumos-gate/commit/0713e232b7712cd27d99e1e935ebb8d5de61c57d

Did anyone else ever encounter this issue?

Please let me know,

Long Ma



-------------------------------------------
illumos-zfs
Archives: https://www.listbox.com/member/archive/182191/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182191/23047029-187a0c8d
Modify Your Subscription: https://www.listbox.com/member/?member_id=23047029&id_secret=23047029-2e85923f
Powered by Listbox: http://www.listbox.com
George Wilson
2014-03-14 22:21:18 UTC
Permalink
This looks like a legitimate bug. Sorry about that. I will send out a
review with the fix.

- George
Post by Long Ma
Hi everyone,
I noticed something odd in current metaslab code. In the metaslab.c
file, the "metaslab_group_tasksq" is created in
the metaslab_group_create function but it is not destroyed in
the metaslab_group_destroy function.
I first noticed this problem by doing zpool import. Threadlist shows
that there is an increasing amount of metaslab_group_tasksq being
created but never destroyed.
Repeated use of zpool import will eventually cause the system to hit
the max thread limit.
This is the changeset at which the create_taskq is added into the
https://github.com/illumos/illumos-gate/commit/0713e232b7712cd27d99e1e935ebb8d5de61c57d
Did anyone else ever encounter this issue?
Please let me know,
Long Ma
*illumos-zfs* | Archives
<https://www.listbox.com/member/archive/182191/=now>
<https://www.listbox.com/member/archive/rss/182191/22008002-303f2ff4>
| Modify
<https://www.listbox.com/member/?&>
Your Subscription [Powered by Listbox] <http://www.listbox.com>
-------------------------------------------
illumos-zfs
Archives: https://www.listbox.com/member/archive/182191/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182191/23047029-187a0c8d
Modify Your Subscription: https://www.listbox.com/member/?member_id=23047029&id_secret=23047029-2e85923f
Powered by Listbox: http://www.listbox.com
Tim Chase
2014-03-15 04:50:48 UTC
Permalink
Post by George Wilson
This looks like a legitimate bug. Sorry about that. I will send out a
review with the fix.
- George
Post by Long Ma
Hi everyone,
I noticed something odd in current metaslab code. In the metaslab.c
file, the "metaslab_group_tasksq" is created in
the metaslab_group_create function but it is not destroyed in
the metaslab_group_destroy function.
I first noticed this problem by doing zpool import. Threadlist shows
that there is an increasing amount of metaslab_group_tasksq being
created but never destroyed.
Repeated use of zpool import will eventually cause the system to hit
the max thread limit.
This is the changeset at which the create_taskq is added into the
https://github.com/illumos/illumos-gate/commit/0713e232b7712cd27d99e1e935ebb8d5de61c57d
Did anyone else ever encounter this issue?
Please let me know,
I ran into this when porting this as part of a stack of patches to
zfsonlinux. My fix is in a separate patch in
https://github.com/dweeezil/zfs/commit/69b0687. Interestingly enough,
the context in which I discovered it is that zdb wasn't exiting
properly. My ensuing gdb sessions led to the discovery that this thread
wasn't being destroyed.

- Tim




-------------------------------------------
illumos-zfs
Archives: https://www.listbox.com/member/archive/182191/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182191/23047029-187a0c8d
Modify Your Subscription: https://www.listbox.com/member/?member_id=23047029&id_secret=23047029-2e85923f
Powered by Listbox: http://www.listbox.com
Long Ma
2014-03-15 14:07:43 UTC
Permalink
Thanks for the feedback. That's what I thought, that taskq should have
being destroyed.

Long
Post by George Wilson
This looks like a legitimate bug. Sorry about that. I will send out a
review with the fix.
- George
Hi everyone,
I noticed something odd in current metaslab code. In the metaslab.c file,
the "metaslab_group_tasksq" is created in the metaslab_group_create
function but it is not destroyed in the metaslab_group_destroy function.
I first noticed this problem by doing zpool import. Threadlist shows that
there is an increasing amount of metaslab_group_tasksq being created but
never destroyed.
Repeated use of zpool import will eventually cause the system to hit the
max thread limit.
This is the changeset at which the create_taskq is added into the
https://github.com/illumos/illumos-gate/commit/0713e232b7712cd27d99e1e935ebb8d5de61c57d
Did anyone else ever encounter this issue?
Please let me know,
I ran into this when porting this as part of a stack of patches to
zfsonlinux. My fix is in a separate patch in
https://github.com/dweeezil/zfs/commit/69b0687. Interestingly enough,
the context in which I discovered it is that zdb wasn't exiting properly.
My ensuing gdb sessions led to the discovery that this thread wasn't being
destroyed.
- Tim
*illumos-zfs* | Archives<https://www.listbox.com/member/archive/182191/=now>
<https://www.listbox.com/member/archive/rss/182191/25829441-1a08481c> |
Modify<https://www.listbox.com/member/?&>Your Subscription
<http://www.listbox.com>
-------------------------------------------
illumos-zfs
Archives: https://www.listbox.com/member/archive/182191/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182191/23047029-187a0c8d
Modify Your Subscription: https://www.listbox.com/member/?member_id=23047029&id_secret=23047029-2e85923f
Powered by Listbox: http://www.listbox.com

Loading...