From owner-freebsd-geom@FreeBSD.ORG Sun Mar 8 22:40:19 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 6B7A514B for ; Sun, 8 Mar 2015 22:40:19 +0000 (UTC) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (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 00D34130 for ; Sun, 8 Mar 2015 22:40:18 +0000 (UTC) Received: by wesq59 with SMTP id q59so13727654wes.9 for ; Sun, 08 Mar 2015 15:40:10 -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=3aJE6h5z5Nhrvlm3ljEu/i/MatfvCZeobUpff+escX8=; b=WQnC6Guxhdg8VJ9SQVhyejbAzDYyQtjFAt3lJD3wMMto3BaE5wpdTIHVB3Tqcc5enw 7QTyzoR8EQ9+ojD5xNPxdZy7wYkz7X1FZVBCr9p7HQQe1a2G36PENS3GIHvie7SU2Ag1 ESjYPat24o81/TBJ6CfR8DXBR1BVguthcp/J4CLJBNIDngfqtcbiwnCPKrG6u0qsDMTb MRzShraVq+JCv5CWtE/sJIK1n03CEmg7HeYDucX4CApQG9ERd5tEiyIdG/6kDPADKlHG H4yBLg5xPChR3mj/BTmK0yFVbywsXVhIiPNysxnw+l3zEgVjhs/7k7fveS8/nX3yFTJQ zR0g== X-Gm-Message-State: ALoCoQk6Fy547Kj2VBMhgCQYOuqtmfe+8X6dMpgUkrV+fITE3AJ52WToTjEOoLG9yl5lLpoRS8py X-Received: by 10.180.219.102 with SMTP id pn6mr53173224wic.50.1425854410711; Sun, 08 Mar 2015 15:40:10 -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 lj13sm12842377wic.9.2015.03.08.15.40.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Mar 2015 15:40:09 -0700 (PDT) Message-ID: <54FCCFC3.4000007@multiplay.co.uk> Date: Sun, 08 Mar 2015 22:40:03 +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: "Matthew D. Fuller" Subject: Re: RFC: Pass TRIM through GELI References: <20150308000131.GP1742@over-yonder.net> <54FC4E99.4080202@multiplay.co.uk> <20150308223552.GR1742@over-yonder.net> In-Reply-To: <20150308223552.GR1742@over-yonder.net> 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: Sun, 08 Mar 2015 22:40:19 -0000 On 08/03/2015 22:35, Matthew D. Fuller wrote: > On Sun, Mar 08, 2015 at 01:28:57PM +0000 I heard the voice of > Steven Hartland, and lo! it spake thus: >> I don't see where your checking if the underlying device supports DELETE? > From my understanding (which is hardly authoritative, to be sure, so > I'm open to correction), I don't have to. GELI itself doesn't > originate any BIO_DELETE's, so they're only coming from stuff on top > of us. We just pass those through to what's underneath us and it does > all the answering. If that doesn't support it, it would return an "I > don't do that" response, which the filesystem (or whatever) on top of > us handles[0] its way. So for _DELETE, as for _FLUSH and _GETATTR, > GELI is just transparent. > > Am I mistaken? > Underlying BIO_DELETE support is optional, typically only supported by SSD's via TRIM or UNMAP, so unless you check to see if the device supports it you'll be translating delete so a noop, actually you'll be forcing an extra layer to process the delete when it will never be able to to. Given GEIL is all about security translating the delete to a noop results in a pretty serious security issue I would say as it will leave data which he user intended to be removed present on the device. Regards Steve