From owner-freebsd-geom@FreeBSD.ORG Mon Mar 16 11:55:26 2015 Return-Path: Delivered-To: freebsd-geom@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 8E012C13 for ; Mon, 16 Mar 2015 11:55:26 +0000 (UTC) Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) (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 1B5D1198 for ; Mon, 16 Mar 2015 11:55:25 +0000 (UTC) Received: by webcq43 with SMTP id cq43so36371509web.2 for ; Mon, 16 Mar 2015 04:55:24 -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 :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qOcliF+pdmFnl6GxyPyt9XzdqtBuBTcDl/yjk460loc=; b=jiGp3MkpqGFNL7KiUowYFe06w0kIhqjCoHd3QMzKhPHjqk/2lOS8JlDevsuNYolG0R 3rIEB1MJDZ8Weaq/aY1z4OmU9InqAIPui110r88bmWhYVLPNG3kJnJnc0NIY8gpqKYrh X6BStn2/z7eJWGehkosCwx2Hxw+yELvLo9VVScgfAbsMZNc3gc2XS30+UZhW6l7ZHR3a JTUBn3LroqTFrkz4DwP0HPZjUu72wmCa142GZJojVJZGGqzwQdcnWlVlto9BXWlECzCt whBQ5t+b+1623fc4M4y5ynJhtRcKUj5Dtq+GtphHv7cDvQJPruUi+CHyaQlvV6kdNE5a SGrA== X-Gm-Message-State: ALoCoQlIZ5sfyEGaeWO7RtosAc6tpe4ymqcbe36iNBqqNxV4nbzQJZshI9Ui8xpsB2PCHyZCv8mN X-Received: by 10.180.207.227 with SMTP id lz3mr161647593wic.47.1426506924216; Mon, 16 Mar 2015 04:55:24 -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 dn7sm15025112wid.12.2015.03.16.04.55.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Mar 2015 04:55:23 -0700 (PDT) Message-ID: <5506C4A5.6050109@multiplay.co.uk> Date: Mon, 16 Mar 2015 11:55:17 +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: Pawel Jakub Dawidek 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> <5506AD12.2090603@multiplay.co.uk> <20150316115246.GC1515@garage.freebsd.pl> In-Reply-To: <20150316115246.GC1515@garage.freebsd.pl> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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:55:26 -0000 On 16/03/2015 11:52, Pawel Jakub Dawidek wrote: > 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. > Ahh I see what he's saying now, thx.