Re: [developer] spa_namespace_lock vs sync thread

"Andriy Gapon" wrote: > I've got curious about this while looking into what appears to be a > FreeBSD-specific deadlock: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203864#c13 Here's another spa_namespace_lock-related deadlock: 6 102135 zfskern

Re: [developer] spa_namespace_lock vs sync thread

On Fri, Jul 8, 2016 at 9:03 AM, George Wilson wrote: > Andriy, > > I think this is basically a rule, although I don't think it's stated > anywhere. We do rely heavily on this locking strategy since there are many > places that will hold the namespace lock to prevent

Re: [developer] spa_namespace_lock vs sync thread

George, thank you very much for the reply. I've got curious about this while looking into what appears to be a FreeBSD-specific deadlock: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203864#c13 On 08/07/2016 17:03, George Wilson wrote: > Andriy, > > I think this is basically a rule,

Re: [developer] spa_namespace_lock vs sync thread

Andriy, I think this is basically a rule, although I don't think it's stated anywhere. We do rely heavily on this locking strategy since there are many places that will hold the namespace lock to prevent spa config changes but yet wait for a txg to sync. Is it honored everywhere? Well, I hope so

[developer] spa_namespace_lock vs sync thread

I see a few places in the code that do the following: mutex_enter(_namespace_lock); dsl_sync_task(...); mutex_exit(_namespace_lock); One example is spa_change_guid(). In my understanding this implies that the sync thread must never acquire spa_namespace_lock. Is this a