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 but there probably hasn't been a detailed analysis done to see if there might be places where we do something like a spa_open() from some obscure path in the sync thread. I would hope that our testing would have discovered that quickly and hopefully developers will sufficiently exercise their code to make sure they don't violate this. Have you seen instances where we deadlock as a result of this? Thanks, George On Fri, Jul 8, 2016 at 9:40 AM, Andriy Gapon <a...@freebsd.org> wrote: > > I see a few places in the code that do the following: > mutex_enter(&spa_namespace_lock); > dsl_sync_task(...); > mutex_exit(&spa_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 real rule? Do we always honor it? > > Thank you! > -- > Andriy Gapon > ------------------------------------------- openzfs-developer Archives: https://www.listbox.com/member/archive/274414/=now RSS Feed: https://www.listbox.com/member/archive/rss/274414/28015062-cce53afa Modify Your Subscription: https://www.listbox.com/member/?member_id=28015062&id_secret=28015062-f966d51c Powered by Listbox: http://www.listbox.com
