From owner-svn-src-all@freebsd.org Tue Jan 19 18:55:07 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6C894A891F0 for ; Tue, 19 Jan 2016 18:55:07 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 331231E6F for ; Tue, 19 Jan 2016 18:55:07 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ob0-x22f.google.com with SMTP id vt7so195015311obb.1 for ; Tue, 19 Jan 2016 10:55:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:cc:content-type; bh=oxzSOOM9B6k8Pd0wN+zYHieJ0wlzoaeNfjtS7i1kz14=; b=T4DxyKKx0yzg0pRlrrgmQX7JMPoRxiibOBgnoew55pyAluA9ZnXO6Rq/VUZf7kT68H zWqSRKpnemQnlg8lP8nZREmQog9+hYilTaOVgD/3vcTGvJlomqw7IQQAZNV2Dv9TTs6B JM8UnJ4SuiA7upHmhwx3K6MdvS6CjXDKxbW717NX0EHVErH9Wj/HWp+/kepxoaERALE7 gXNZWmwLnP14kCYC28pJGDMXwvQEtmL1+hzixJtskE+DGV5b5BF5D46YirWmTmOpHdgf vA2YiSLRvI8sP84PoJRfw49JKpkV5wD1mGX1ZlBQuUWqQGaGqtJISxgdGYqNXqwQKCyF MH8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:cc:content-type; bh=oxzSOOM9B6k8Pd0wN+zYHieJ0wlzoaeNfjtS7i1kz14=; b=UbXOyaEm6f+YV4YdEY22xd7LK3s5yMC4Rw8myQIkc/HYzTsTBRIdw2kJSjc2QiO9Kd utK4xMT6myskEA6L8RW7SG7QSDdFvXN/RjX+KLxO9PM6fG4etABXuiPZzqtbHQBF7N2h 6rCd7CVhaqbB/JYWJXMdcj6FEckfuRXYv23+QoC3K1aiWYkVY3oFEUfqXC5uxXq8Tk3h W6fni1yNJvFDsYx2m663uFlV1KXOKYqrhb/7TCkwmifzIeYFnGaC31ZUKp5gFCF8djOc TU2+q2+M43ahEbBHgXo+02/WZ0DfejbJ1TZ3gElo0t8K6xaSrh7041kJwuhyVG+dLPbn 7Bfg== X-Gm-Message-State: ALoCoQlBJQ+rX1MkfcmBwb0S4bgfgF7wV1mszoR5EahfhiuQyLzVdDob/UMNjIAt9Nu4ZgKqIL37Rt5x8KiCfysXLw2aJvA+1A== MIME-Version: 1.0 X-Received: by 10.60.226.136 with SMTP id rs8mt26974126oec.31.1453229706503; Tue, 19 Jan 2016 10:55:06 -0800 (PST) Sender: asomers@gmail.com Received: by 10.202.69.84 with HTTP; Tue, 19 Jan 2016 10:55:06 -0800 (PST) In-Reply-To: <201601191700.u0JH0P6k061610@repo.freebsd.org> References: <201601191700.u0JH0P6k061610@repo.freebsd.org> Date: Tue, 19 Jan 2016 11:55:06 -0700 X-Google-Sender-Auth: eB9CBEdOX_j55vYCz09qBmOirQ8 Message-ID: Subject: Re: svn commit: r294329 - in head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs: . sys From: Alan Somers Cc: "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 18:55:07 -0000 On Tue, Jan 19, 2016 at 10:00 AM, Alan Somers wrote: > Author: asomers > Date: Tue Jan 19 17:00:25 2016 > New Revision: 294329 > URL: https://svnweb.freebsd.org/changeset/base/294329 > > Log: > Disallow zvol-backed ZFS pools > > Using zvols as backing devices for ZFS pools is fraught with panics and > deadlocks. For example, attempting to online a missing device in the > presence of a zvol can cause a panic when vdev_geom tastes the zvol. Better > to completely disable vdev_geom from ever opening a zvol. The solution > relies on setting a thread-local variable during vdev_geom_open, and > returning EOPNOTSUPP during zvol_open if that thread-local variable is set. > > Remove the check for MUTEX_HELD(&zfsdev_state_lock) in zvol_open. Its intent > was to prevent a recursive mutex acquisition panic. However, the new check > for the thread-local variable also fixes that problem. > > Also, fix a panic in vdev_geom_taste_orphan. For an unknown reason, this > function was set to panic. But it can occur that a device disappears during > tasting, and it causes no problems to ignore this departure. > > Reviewed by: delphij > MFC after: 1 week > Relnotes: yes > Sponsored by: Spectra Logic Corp > Differential Revision: https://reviews.freebsd.org/D4986 > > Modified: > head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev_impl.h > head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c > head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c > head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c > > Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev_impl.h Due to popular demand, I will conditionalize this behavior on a sysctl, and I won't MFC it. The sysctl must default to off (ZFS on zvols not allowed) because having the ability to put pools on zvols can cause panics even for users who aren't using it. And let me clear up some confusion: 1) Having the ability to put a zpool on a zvol can cause panics and deadlocks, even if that ability is unused. 2) Putting a zpool atop a zvol causes unnecessary performance problems because there are two layers of COW involved, with all their software complexities. This also applies to putting a zpool atop files on a ZFS filesystem. 3) A VM guest putting a zpool on its virtual disk, where the VM host backs that virtual disk with a zvol, will work fine. That's the ideal use case for zvols. 3b) Using ZFS on both host and guest isn't ideal for performance, as described in item 2. That's why I prefer to use UFS for VM guests. 4) Using UFS on a zvol as Stefen Esser described works fine. I'm not aware of any performance problems associated with mixing UFS and ZFS. Perhaps Stefan was referring to duplication between the ARC and UFS's vnode cache. The same duplication would be present in a ZFS on top of zvol scenario. -Alan