From owner-freebsd-geom@FreeBSD.ORG Mon Mar 16 11:50:02 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 0C44CB18 for ; Mon, 16 Mar 2015 11:50:02 +0000 (UTC) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id C515CC1 for ; Mon, 16 Mar 2015 11:50:00 +0000 (UTC) Received: from localhost (unknown [91.206.210.241]) by mail.dawidek.net (Postfix) with ESMTPSA id 91AA2E4F; Mon, 16 Mar 2015 12:49:58 +0100 (CET) Date: Mon, 16 Mar 2015 12:52:46 +0100 From: Pawel Jakub Dawidek To: Steven Hartland Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150316115246.GC1515@garage.freebsd.pl> 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> <5506AD12.2090603@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5506AD12.2090603@multiplay.co.uk> X-OS: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-geom@freebsd.org 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 11:50:02 -0000 On Mon, Mar 16, 2015 at 10:14:42AM +0000, Steven Hartland wrote: > > 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. By ZFS is at the top of the stack, GELI is just passing through the requests. I agree with Matt that ZFS is the one who should handle EOPNOTSUPP from the underlying provider, not GELI. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com