On Fri, Jul 8, 2016 at 11:21 AM, Albert Lee <[email protected]> wrote:
> On Fri, Jul 8, 2016 at 9:03 AM, George Wilson <[email protected]> > 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 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 >> >> > Waiting for txg sync while holding spa_namespace_lock can lead to an > unecoverable state if the pool I/O gets suspended. I've seen this with a > failed import where spa_config_update is blocked: > https://www.illumos.org/issues/2607 > > -Albert > Yeah, there are lots of combinations where this can happen. Anytime the pool suspends you are almost guaranteed to deadlock on the spa_namespace_lock. This will probably need some significant restructuring to address it. - George > > >> On Fri, Jul 8, 2016 at 9:40 AM, Andriy Gapon <[email protected]> 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 >>> >>> >>> http://www.listbox.com >>> >> >> *openzfs-developer* | Archives >> <https://www.listbox.com/member/archive/274414/=now> >> <https://www.listbox.com/member/archive/rss/274414/28015425-16c03b8c> | >> Modify <https://www.listbox.com/member/?&;> Your Subscription >> <http://www.listbox.com> >> > > *openzfs-developer* | Archives > <https://www.listbox.com/member/archive/274414/=now> > <https://www.listbox.com/member/archive/rss/274414/28015172-7a646cd5> | > Modify > <https://www.listbox.com/member/?&;> > Your Subscription <http://www.listbox.com> > ------------------------------------------- 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
