svn commit: r294329 - in head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs: . sys

Alan Somers asomers at freebsd.org
Tue Jan 19 17:20:39 UTC 2016


On Tue, Jan 19, 2016 at 10:08 AM, Kurt Lidl <lidl at pix.net> 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]
>
>


More information about the svn-src-head mailing list