From owner-freebsd-fs@FreeBSD.ORG Sat Mar 14 17:37:25 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 907269C4 for ; Sat, 14 Mar 2015 17:37:25 +0000 (UTC) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (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 22F97C1E for ; Sat, 14 Mar 2015 17:37:24 +0000 (UTC) Received: by wifj2 with SMTP id j2so10880841wif.1 for ; Sat, 14 Mar 2015 10:37:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=P0eLQZNLN03j4UaSKf1/z22mgWFpTVnFQvtgXwIn3g8=; b=Pf8K+SOs5STkTaoOgXd0ndgyZSiSlzoEKGe71CbN21gm8yQ3HnfvQgZpn93tWrGb4d wozaTfJ/LpFwCy802ecaUZX1yfHwqicgQ6VZfGoF8K2fYXM2dznSMRjObvSAJQKbLxwG DUXaEzvUxpoITZGBmTm9sZeAi6IL8EYT/MYsl/4NiZkxT4me2lcVMABHTJQYjJmQbgTf wuwQL5YbqxWKzFRC1+oNBbvpu7pNQhYjQIn0pLldhXmKlVU8YY3VeeNrysMnY0ktIbKT lxyQWPg+2Q/rZFE1iAA2EzNbUtGMJerzgpqouIj4wip6Ez1Nlz/GzGD9un8iLm9nmag8 vc1Q== X-Gm-Message-State: ALoCoQlrQnd9yQcmxIzBSN9tbZU/6/bH/9iZffPu16g0JpRHpczl+QN+fRZf1PNeDxfxqKHpFVi3 X-Received: by 10.180.7.196 with SMTP id l4mr125542728wia.44.1426354636720; Sat, 14 Mar 2015 10:37:16 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id fo9sm7792491wib.16.2015.03.14.10.37.15 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Mar 2015 10:37:15 -0700 (PDT) Message-ID: <550471C3.7010409@multiplay.co.uk> Date: Sat, 14 Mar 2015 17:37:07 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: Troubles with zvol + BIO_DELETE References: <20150314163641.GK24274@over-yonder.net> In-Reply-To: <20150314163641.GK24274@over-yonder.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 17:37:25 -0000 On 14/03/2015 16:36, Matthew D. Fuller wrote: > 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; > } This is correct I've just committed the fix with a slight change so other bio types don't get lost too: https://svnweb.freebsd.org/changeset/base/279996 Its scheduled for MFC in two weeks. Thanks for this Matthew :) Regards Steve