From nobody Wed Sep 29 13:05:11 2021 X-Original-To: fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D5F5417CBDE7 for ; Wed, 29 Sep 2021 13:05:23 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com [209.85.210.50]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HKGnb46gDz3j5r; Wed, 29 Sep 2021 13:05:23 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f50.google.com with SMTP id 5-20020a9d0685000000b0054706d7b8e5so2764556otx.3; Wed, 29 Sep 2021 06:05:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9dfsGSmcm2t+/o/QBZjBpLqIGod8H77SN4Qmk+o5fAw=; b=mHuqmD0B9q2pylYrx9Frf/BVzwu7gKFoUQ+wyBd1XuroId/FPAtPkuATehpQsW+KnQ iir2Fg1LGyyDCPCpCezL+da6h9DhmQPyh4VXHYXF/NDNeeyVC60aueqNo9TzGg5zPw3h fjkZ45xXtiQIyLcWg9mi9mHTumsMofsFGXintYLoRX0EoQVQ+qtk/GadbfIGmUSJg+Gl wHEZcfnEFSuuJci782gegnWLCOP46A5jKFA0kgssoffymZwJsFkaUxZR/9y0iYldv3Kx s7nWFz6opthd9sVDSsLmrSt50W8cyfaOk9QYcTb6E3asO60R+Z3QbsasfqrsqL3rTQ6v poBQ== X-Gm-Message-State: AOAM533E4f3aM9FRZO/jTO9XP2Bc+MFD8y4IAi5XH5yrW50d9q2V5OJN 3eQT+mU3wrTvQ6lS8t82+wp7ALH2qZi0vLwQMlEQMTMc7XI= X-Google-Smtp-Source: ABdhPJwl5gDahPcFmvnk4TCE1C1CAm0niHtq1VWq1AGh6EodU2jCQgEWgZnLCmyLslLKi8jeiIsQ63w7Q/n5PRUs9g8= X-Received: by 2002:a05:6830:2783:: with SMTP id x3mr10120366otu.371.1632920722651; Wed, 29 Sep 2021 06:05:22 -0700 (PDT) List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 References: <10583cba-c2f5-ffbe-5a1b-8dfcd8114b4d@FreeBSD.org> In-Reply-To: <10583cba-c2f5-ffbe-5a1b-8dfcd8114b4d@FreeBSD.org> From: Alan Somers Date: Wed, 29 Sep 2021 07:05:11 -0600 Message-ID: Subject: Re: vfs.zfs.vol.recursive completely broken, time to remove? To: Andriy Gapon Cc: freebsd-fs Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4HKGnb46gDz3j5r X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On Wed, Sep 29, 2021 at 12:10 AM Andriy Gapon wrote: > > > It seems that while previously there could sometimes be a deadlock with > vfs.zfs.vol.recursive=1, now it is guaranteed. > > There was an OpenZFS change to use a pool of threads for vdev opening (to > parallelize / speed up). When such a thread opens a zvol it needs to acquire > spa_namespace_lock. But the lock is already held by a thread requesting the > operation such as a thread doing zpool import (spa_load). > So, it's an obvious deadlock: the main thread is waiting for the workers while > holding the namespace lock, at least one of the workers is blocked on the same lock. The last time I tried that there was pushback from a lot of different people. I think we need to fix it instead. Here's the beginning of that flame war. https://docs.freebsd.org/cgi/getmsg.cgi?fetch=1031189+0+archive/2016/svn-src-all/20160124.svn-src-all