From owner-freebsd-fs@FreeBSD.ORG Sat Mar 14 16:36:44 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B363E66 for ; Sat, 14 Mar 2015 16:36:44 +0000 (UTC) Received: from thyme.infocus-llc.com (thyme.infocus-llc.com [199.15.120.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E93E069E for ; Sat, 14 Mar 2015 16:36:43 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 2026137B586 for ; Sat, 14 Mar 2015 11:36:42 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3l48fx3w3nz2jv; Sat, 14 Mar 2015 11:36:41 -0500 (CDT) Date: Sat, 14 Mar 2015 11:36:41 -0500 From: "Matthew D. Fuller" To: freebsd-fs@freebsd.org Subject: Troubles with zvol + BIO_DELETE Message-ID: <20150314163641.GK24274@over-yonder.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.23-fullermd.4 (2014-03-12) X-Virus-Scanned: clamav-milter 0.98.6 at thyme.infocus-llc.com X-Virus-Status: Clean X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 16:36:44 -0000 In some GELI messing, we've found some bad behavior in sending DELETE's through to a backing zvol. After investigation, my best guess is that this is actually a bug in the zvol code. The requests come into zvol_geom_start(). In "normal" cases (e.g., when doing a newfs directly on the zvol), the bio's seem to go straight through to zvol_strategy(). However, when going through GELI, we hit the !THREAD_CAN_SLEEP() case, and so they get queued up. Then zvol_geom_worker() deals with them later. However, it doesn't know anything about BIO_DELETE; there's no handling at all. So at that point, the request just hangs around pending forever. I'm pretty sure it should just get send to zvol_strategy() the same as READ/WRITE do: Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c (revision 279210) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c (working copy) @@ -2775,6 +2775,7 @@ break; case BIO_READ: case BIO_WRITE: + case BIO_DELETE: zvol_strategy(bp); break; } -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.