From owner-freebsd-geom@FreeBSD.ORG Mon Mar 16 10:14:57 2015 Return-Path: Delivered-To: freebsd-geom@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 9B08A72D for ; Mon, 16 Mar 2015 10:14:57 +0000 (UTC) Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.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 2A630379 for ; Mon, 16 Mar 2015 10:14:56 +0000 (UTC) Received: by weop45 with SMTP id p45so8965872weo.0 for ; Mon, 16 Mar 2015 03:14:49 -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=dM57sNrvcOpmCb5hLXcBvc0Wbk7CD4HOXgmsEPCwXIU=; b=UL2LHlAOPeppSXVb41S27n7VUydV9djToKsbeG1aqs1SEuZfqJ1w8F7pqtuyjH2hfD sXq1o62eQGDFLPseZpV5szz7DpPXyBl2DTxMC++CT7OD9gko4j22L/6SXKH6v4tRQal8 +nAUeyPR8FghlA219F+ErLbGwXyAA3GDTcK8tvyTI2m9FAfyauRPrVI9QeAL0WM+WSUV c6LupIiE5PpiCxFIk9aVIJYuKovoozK5o4hMMAYXpu3MvsGSiaqJFJIsEcqLPTxWqRsC xOLGjrGPsHGO6Uf/bssitIRFoGtc/KcWXYhc8SlqTFuFMhM1zF5E7FRMlQYvXY8Wj+AN hLhg== X-Gm-Message-State: ALoCoQlq2UmHdG8qjvCrdm94BhWQ7+9ODpjczMPs2aExQ+IovS1inmO1per4qCO0zt8RCCQ+26EX X-Received: by 10.194.86.194 with SMTP id r2mr123820617wjz.41.1426500889355; Mon, 16 Mar 2015 03:14:49 -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 fm10sm14666280wib.7.2015.03.16.03.14.47 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Mar 2015 03:14:47 -0700 (PDT) Message-ID: <5506AD12.2090603@multiplay.co.uk> Date: Mon, 16 Mar 2015 10:14:42 +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-geom@freebsd.org Subject: Re: RFC: Pass TRIM through GELI References: <20150308000131.GP1742@over-yonder.net> <20150314151453.GJ24274@over-yonder.net> <501bca86.508d8e26@fabiankeil.de> <20150315145324.GA52331@over-yonder.net> <20150315182444.GB52331@over-yonder.net> <20150316010845.GA1515@garage.freebsd.pl> <20150316092126.GC52331@over-yonder.net> In-Reply-To: <20150316092126.GC52331@over-yonder.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 10:14:57 -0000 On 16/03/2015 09:21, Matthew D. Fuller wrote: > On Mon, Mar 16, 2015 at 02:08:45AM +0100 I heard the voice of > Pawel Jakub Dawidek, and lo! it spake thus: >> Overall the patch looks good. The main concern I have is that we do >> nothing if the underlying provider returns EOPNOTSUPP on BIO_DELETE, >> we will just keep sending those requests. > Well, they're all coming from the layer above us, and it'll get back > the EOPNOTSUPP's, so if it keeps sending them anyway that seems more > like its problem than ours. It seems like intercepting the response > (that would mean making our own new request, getting the response, > then making that response ourselves to the original?) wouldn't really > save much of anything, and adds a lot of extra bug-havens... > See how ZFS details with this, it adds internal state to the device which stores and bypasses the pass down after the first EOPNOTSUPP. This avoids the full stack round trip, which when volumes of deletes are high could be noticeable. Regards Steve