From owner-svn-src-all@freebsd.org Tue Jan 19 17:20:39 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 175E3A8662F; Tue, 19 Jan 2016 17:20:39 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (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 D26A31A0D; Tue, 19 Jan 2016 17:20:38 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ob0-x232.google.com with SMTP id is5so192556492obc.0; Tue, 19 Jan 2016 09:20:38 -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:to:cc:content-type; bh=9mQl9TcUYIl0+x2VAXpY2YjizeYuoUd0A49Xlmfe+Mk=; b=c4DvgQ+7lDnLL96QaDcSnZxGluKvZD2qKzjWcdqhSQOosHyOJjvkB8gP+GH9oQiat/ qf0KLFk6J8fv1fyWMlJeRuvefHwDRPC+No7npcuFM/Ik9Mh1UafaImpPuuuREfiqGm9e zHkp42LeUI/s+aMqmn2Srmd3bSuevl1t15haqnuS+TBkYefWGgBWrFyYjux6xPqyjr7f b5mPuyKArbR0s65ReNZ+ZsNhlamCisVSoMF7+ITjWoFvvm7BJp19jG4+jsMNwOawBBqy 75ORW5HPfcqFuywxF+9gP1oAQ0dhlu5VYK1fiDvB9YeP7FiOcYO9sciL86nvNrlkJDdB gpfg== 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:to:cc:content-type; bh=9mQl9TcUYIl0+x2VAXpY2YjizeYuoUd0A49Xlmfe+Mk=; b=KLbl36ar4qN5T8xIc/dmFxFm+N4oTXxkocMXO77DBu0s1vLjPMRHOpWILFD9jMoMtD y/Rhc+wcAortEQ8whKndpgxBPHCtKbxxL67Xti12rHk69wDKkg3/ICpUPu096XzjTmoF JGfjC/ZqVW0CCVCZ6k3kTYBcHwj15SATV71O7+XLMaIFDsk8HtzmJhwQgCmW/IxgaHsv o3gWr4NqI8MDQmPgGpeuHlRO4d2tfMU9ivumh/F5evk3SRwpCvDgo0YXTZox49cuI88M JcM9ZNpOUjs/j21CPSdBa116C0SlQoGOxrM3Q69f3G5uZRp4AR0OfRtdYlJ5HO7Xvffe mIJg== X-Gm-Message-State: AG10YOTMi7IpeSJfotY7iZd+v7339jPaCXjVYWFG3lzCQfGkvLf/hnqgI3gmdasoATl8oAoXEC3pRgUaSeP9rw== MIME-Version: 1.0 X-Received: by 10.182.213.71 with SMTP id nq7mr13532917obc.65.1453224038183; Tue, 19 Jan 2016 09:20:38 -0800 (PST) Sender: asomers@gmail.com Received: by 10.202.69.84 with HTTP; Tue, 19 Jan 2016 09:20:38 -0800 (PST) In-Reply-To: <569E6DA0.9010300@pix.net> References: <201601191700.u0JH0P6k061610@repo.freebsd.org> <569E6DA0.9010300@pix.net> Date: Tue, 19 Jan 2016 10:20:38 -0700 X-Google-Sender-Auth: 0B0yngL4KJwMePaRAFXH9Y84ULc Message-ID: Subject: Re: svn commit: r294329 - in head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs: . sys From: Alan Somers To: Kurt Lidl 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 17:20:39 -0000 On Tue, Jan 19, 2016 at 10:08 AM, Kurt Lidl wrote: > Removing the ability to run different zpools on top of a zvol is > a significant reduction in functionality of the entire system, and a huge > violation of the POLA. The thing is, it never really worked in the first place. Panics and deadlocks are so frequent that I don't think the feature was usable for anybody. > > At the very least, can you not add a sysctl that allows the > dangerous behavior (even if it defaults to off)? Myself > and certainly others rely on having being able to use a zpool > installed into a zvol for hosting bhyve virtual machines. Your use case should be unaffected. The guest has a different ZFS instance than the host, so it should work just fine. Please let me know if you have problems. -Alan > > I've managed to deadlock the system when experimenting with this, > but for the normal course of operations, it works just fine. > > -Kurt > > > On 1/19/16 12:00 PM, 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 > > > [diff truncated] > >