From owner-freebsd-geom@FreeBSD.ORG Sun Mar 8 00:09:44 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 ED2EFBF4; Sun, 8 Mar 2015 00:09:44 +0000 (UTC) Received: from thyme.infocus-llc.com (thyme.infocus-llc.com [199.15.120.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AB004929; Sun, 8 Mar 2015 00:09:43 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 0218237B55B; Sat, 7 Mar 2015 18:01:32 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3l02sR1WzVz22S; Sat, 7 Mar 2015 18:01:31 -0600 (CST) Date: Sat, 7 Mar 2015 18:01:31 -0600 From: "Matthew D. Fuller" To: freebsd-geom@freebsd.org Subject: RFC: Pass TRIM through GELI Message-ID: <20150308000131.GP1742@over-yonder.net> MIME-Version: 1.0 X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.23-fullermd.4 (2014-03-12) X-Virus-Scanned: clamav-milter 0.98.6 at thyme.infocus-llc.com X-Virus-Status: Clean Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: pjd@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 00:09:45 -0000 [ bcc'd to -fs because it's been discussed there in the past; followup to -geom because that seems where it belongs ] I've done a quick implementation of TRIM passthru support for GELI. Patch attached is against late Feb -CURRENT; however, a glance at svn suggests this code hasn't changed much, so it's probably pretty portable forward and back. It applies cleanly to a stable/10 tree though I haven't tried compiling or using it there. This has been lightly tested and seems to work fine. It adds a '-t' flag to init and onetime to enable passthru on the new provider, and '-t/-T' options to configure to en/disable on existing (but see caveat below about metadata versions; as written, you can't use this on existing partitions). Since all we're doing is passing it through instead of denying it, I'd expect "seems to work" to be pretty much the same as "does work"; the requests go through, space clears up, and messing with a little ZFS on top of it doesn't show up any data corruption. The patch to gnop in is a useful adjunct in checking when/if the requests actually go through, by making the .eli on top of the .nop and seeing when the counters tick. In this implementation, I added a new G_ELI_VERSION and required it for setting the flag. I actually think this is probably not necessary; all we do is set a value in the flags field, and if it's loaded onto a system that doesn't know what to do with that value, it'll just do nothing, which IMO is fine. And since there is no `geli upgrade`, this means that you can't enable it on any existing partitions, but have to kill/init from scratch, which isn't very user-friendly. So I propose that it actually be done sans those version changes, but they are in the patch as attached for now. One not-quite-related change in here is that I added a denial for 'geli configure' attempts on onetime providers. Trying this causes a panic, as the metadata version field on onetime providers is nonsensical. As far as I can tell in quick testing, this isn't related to my changes; it happens with stock GELI code as well. Presumably it's never been noticed before since the only prior use for 'geli configure' was to un/set the BOOT flag, which makes no sense on a onetime anyway, so nobody ever bothered trying. But with -[tT], somebody might try. Evidence: I did, and found the panic :) -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-geom@FreeBSD.ORG Sun Mar 8 00:15:54 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 C6299C6D for ; Sun, 8 Mar 2015 00:15:54 +0000 (UTC) Received: from thyme.infocus-llc.com (thyme.infocus-llc.com [199.15.120.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9F2159D2 for ; Sun, 8 Mar 2015 00:15:54 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 8142937B402 for ; Sat, 7 Mar 2015 18:15:53 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3l03B067PWz22k; Sat, 7 Mar 2015 18:15:52 -0600 (CST) Date: Sat, 7 Mar 2015 18:15:52 -0600 From: "Matthew D. Fuller" To: freebsd-geom@freebsd.org Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150308001552.GQ1742@over-yonder.net> References: <20150308000131.GP1742@over-yonder.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150308000131.GP1742@over-yonder.net> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.23-fullermd.4 (2014-03-12) X-Virus-Scanned: clamav-milter 0.98.6 at thyme.infocus-llc.com X-Virus-Status: Clean 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 00:15:54 -0000 > Patch attached was stripped by the mailing list. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-geom@FreeBSD.ORG Sun Mar 8 13:29:14 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 E0415FD3 for ; Sun, 8 Mar 2015 13:29:13 +0000 (UTC) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (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 76772E13 for ; Sun, 8 Mar 2015 13:29:12 +0000 (UTC) Received: by widfb4 with SMTP id fb4so3368270wid.0 for ; Sun, 08 Mar 2015 06:29:05 -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=UbOCfEIB6v8f3Ozxnws2udab9yPg9tNfva8p3IVCbaE=; b=UdzN2cksvQlvOJpRh/KGDfEaty2yxpkjmteS+nEUL4PS0ZrJf8j3TGEn3F6oDJplot ZMR70jmG126bWTVBsopcokR1ctjNs+6+eWFvZ4dutY1cxjFabXYhslIEXJjBke320qNw Gtks2Dy40JcZtn+abL2oCkq0S+rSYndxzwnZsRda4ofFBLRCx0j+7L1vi4ib4gWZMDdA GxRmNEfw5ew2fFDVHSqdJXsOyeb8ttZMYzXBqZRV6bkJIFeEN+tODjizEPWDL53uxIUx 79+c0+GRX4sBFjrQD18mS/az/fCAfNkuqR+g49uh4GSFItIlg4pJD6oKqVXhoin/tiqX XewA== X-Gm-Message-State: ALoCoQlcyIt5d1nKnu5ptZ/U9oixvwUuDdreldMaIfFkOe47YXWF3Y2ccP2ZA618uBI3yz7oyMmb X-Received: by 10.180.109.70 with SMTP id hq6mr11762611wib.16.1425821345212; Sun, 08 Mar 2015 06:29:05 -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 cf12sm23809014wjb.10.2015.03.08.06.29.03 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Mar 2015 06:29:04 -0700 (PDT) Message-ID: <54FC4E99.4080202@multiplay.co.uk> Date: Sun, 08 Mar 2015 13:28:57 +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> In-Reply-To: <20150308000131.GP1742@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: Sun, 08 Mar 2015 13:29:14 -0000 I don't see where your checking if the underlying device supports DELETE? On 08/03/2015 00:01, Matthew D. Fuller wrote: > [ bcc'd to -fs because it's been discussed there in the past; followup > to -geom because that seems where it belongs ] > > I've done a quick implementation of TRIM passthru support for GELI. > Patch attached is against late Feb -CURRENT; however, a glance at svn > suggests this code hasn't changed much, so it's probably pretty > portable forward and back. It applies cleanly to a stable/10 tree > though I haven't tried compiling or using it there. > > This has been lightly tested and seems to work fine. It adds a '-t' > flag to init and onetime to enable passthru on the new provider, and > '-t/-T' options to configure to en/disable on existing (but see caveat > below about metadata versions; as written, you can't use this on > existing partitions). > > Since all we're doing is passing it through instead of denying it, I'd > expect "seems to work" to be pretty much the same as "does work"; the > requests go through, space clears up, and messing with a little ZFS on > top of it doesn't show up any data corruption. > > The patch to gnop in > is a useful > adjunct in checking when/if the requests actually go through, by > making the .eli on top of the .nop and seeing when the counters tick. > > > In this implementation, I added a new G_ELI_VERSION and required it > for setting the flag. I actually think this is probably not > necessary; all we do is set a value in the flags field, and if it's > loaded onto a system that doesn't know what to do with that value, > it'll just do nothing, which IMO is fine. And since there is no `geli > upgrade`, this means that you can't enable it on any existing > partitions, but have to kill/init from scratch, which isn't very > user-friendly. So I propose that it actually be done sans those > version changes, but they are in the patch as attached for now. > > > One not-quite-related change in here is that I added a denial for > 'geli configure' attempts on onetime providers. Trying this causes a > panic, as the metadata version field on onetime providers is > nonsensical. As far as I can tell in quick testing, this isn't > related to my changes; it happens with stock GELI code as well. > Presumably it's never been noticed before since the only prior use for > 'geli configure' was to un/set the BOOT flag, which makes no sense on > a onetime anyway, so nobody ever bothered trying. But with -[tT], > somebody might try. Evidence: I did, and found the panic :) > > From owner-freebsd-geom@FreeBSD.ORG Sun Mar 8 22:35:55 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 12568DA6 for ; Sun, 8 Mar 2015 22:35:55 +0000 (UTC) Received: from thyme.infocus-llc.com (thyme.infocus-llc.com [199.15.120.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DEA8FFC for ; Sun, 8 Mar 2015 22:35:54 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 4495E37B547; Sun, 8 Mar 2015 17:35:53 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3l0cw84z3kz2NZ; Sun, 8 Mar 2015 17:35:52 -0500 (CDT) Date: Sun, 8 Mar 2015 17:35:52 -0500 From: "Matthew D. Fuller" To: Steven Hartland Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150308223552.GR1742@over-yonder.net> References: <20150308000131.GP1742@over-yonder.net> <54FC4E99.4080202@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54FC4E99.4080202@multiplay.co.uk> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.23-fullermd.4 (2014-03-12) X-Virus-Scanned: clamav-milter 0.98.6 at thyme.infocus-llc.com X-Virus-Status: Clean 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:35:55 -0000 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? [0] Well, or doesn't, but that's it's problem, not ours. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. 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 From owner-freebsd-geom@FreeBSD.ORG Sun Mar 8 22:50:48 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 7E405344 for ; Sun, 8 Mar 2015 22:50:48 +0000 (UTC) Received: from thyme.infocus-llc.com (thyme.infocus-llc.com [199.15.120.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 55C7420F for ; Sun, 8 Mar 2015 22:50:48 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 45ACB37B58D; Sun, 8 Mar 2015 17:50:47 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3l0dFL55Gfz2P0; Sun, 8 Mar 2015 17:50:46 -0500 (CDT) Date: Sun, 8 Mar 2015 17:50:46 -0500 From: "Matthew D. Fuller" To: Steven Hartland Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150308225046.GS1742@over-yonder.net> References: <20150308000131.GP1742@over-yonder.net> <54FC4E99.4080202@multiplay.co.uk> <20150308223552.GR1742@over-yonder.net> <54FCCFC3.4000007@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54FCCFC3.4000007@multiplay.co.uk> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.23-fullermd.4 (2014-03-12) X-Virus-Scanned: clamav-milter 0.98.6 at thyme.infocus-llc.com X-Virus-Status: Clean 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:50:48 -0000 On Sun, Mar 08, 2015 at 10:40:03PM +0000 I heard the voice of Steven Hartland, and lo! it spake thus: > > 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. But we're not translating it to anything; we're just passing it along. Certainly in my testing (Virtualbox-provided ada0, which doesn't TRIM, and md(4), which does) ufs and zfs seem to get the message just fine. If a poorly-behaved filesystem ignores the "I don't support that" message from our provider (SSD, hard drive, md(4), whatever), wouldn't it ignore us just the same? -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-geom@FreeBSD.ORG Sun Mar 8 23:05:38 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 B9F877C9 for ; Sun, 8 Mar 2015 23:05:38 +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 5A3993CE for ; Sun, 8 Mar 2015 23:05:38 +0000 (UTC) Received: by wesp10 with SMTP id p10so1766255wes.11 for ; Sun, 08 Mar 2015 16:05:37 -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=PRqGr8ut+2YDujD4tQlP8KRaGrKNzcNOqbOeMzeuzWY=; b=BQayhikh2GoaACFJ5PGqkQiO7AW+phc/c58UDQG9EZ/S+UNta9E446WAS3asnVnHrn KySG0YmvMerDcQoF11lA+jE+ItD4KgFCxsTsMfODSSrNijwopINBObBdbAoM4l9wGyA8 IwdXrqKhq1vuGOOBP7i9rIFQOIj+uQSOak97LjvC0cPalcv5SlvwU2BtqxbluI7pc9YC zpfBv1wt0UO3Otsto3243AqVtT6LLnLQ+29OYbpQkCugGLNgBsXLBrnginDK1vDMfOP8 Gx957FGalQTkr8eVO+zDBwLrLmNUQS6ikibcVlHpY192CHHIyCdTmJYvdsxipDB9HRU9 0F6A== X-Gm-Message-State: ALoCoQnvb4EQduCVAwSWAfgXzv4qfrBEaU8L8zbj4iXxAgciNbxuZk2UY0XQAIiPEwnB18nrorEv X-Received: by 10.180.184.230 with SMTP id ex6mr53718486wic.73.1425855936952; Sun, 08 Mar 2015 16:05:36 -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 jy7sm44800703wid.22.2015.03.08.16.05.35 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Mar 2015 16:05:36 -0700 (PDT) Message-ID: <54FCD5B9.3090101@multiplay.co.uk> Date: Sun, 08 Mar 2015 23:05:29 +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> <54FCCFC3.4000007@multiplay.co.uk> <20150308225046.GS1742@over-yonder.net> In-Reply-To: <20150308225046.GS1742@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 23:05:38 -0000 On 08/03/2015 22:50, Matthew D. Fuller wrote: > On Sun, Mar 08, 2015 at 10:40:03PM +0000 I heard the voice of > Steven Hartland, and lo! it spake thus: >> 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. > But we're not translating it to anything; we're just passing it along. > Certainly in my testing (Virtualbox-provided ada0, which doesn't TRIM, > and md(4), which does) ufs and zfs seem to get the message just fine. > If a poorly-behaved filesystem ignores the "I don't support that" > message from our provider (SSD, hard drive, md(4), whatever), wouldn't > it ignore us just the same? IIRC ufs doesn't support TRIM by default, it needs to be manually enabled. ZFS deals with the case and only enables TRIM on devices that enable it, by detecting the not supported error and disabling it for said devices. GELI is kind of different though given is use, I'm sure users of it would expect delete to leave no trace of the data which was there, which is what I was under the impression it does, correct me if I'm wrong? If that assumption is correct the altering is to do nothing if the underlying device doesn't support delete would be a concern. Regards Steve From owner-freebsd-geom@FreeBSD.ORG Sun Mar 8 23:21:47 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 B401C9CA for ; Sun, 8 Mar 2015 23:21:47 +0000 (UTC) Received: from thyme.infocus-llc.com (thyme.infocus-llc.com [199.15.120.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 89E1F78D for ; Sun, 8 Mar 2015 23:21:47 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 07D5B37B5CD; Sun, 8 Mar 2015 18:21:46 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3l0dx53Qvcz2PY; Sun, 8 Mar 2015 18:21:45 -0500 (CDT) Date: Sun, 8 Mar 2015 18:21:45 -0500 From: "Matthew D. Fuller" To: Steven Hartland Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150308232145.GT1742@over-yonder.net> References: <20150308000131.GP1742@over-yonder.net> <54FC4E99.4080202@multiplay.co.uk> <20150308223552.GR1742@over-yonder.net> <54FCCFC3.4000007@multiplay.co.uk> <20150308225046.GS1742@over-yonder.net> <54FCD5B9.3090101@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54FCD5B9.3090101@multiplay.co.uk> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.23-fullermd.4 (2014-03-12) X-Virus-Scanned: clamav-milter 0.98.6 at thyme.infocus-llc.com X-Virus-Status: Clean 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 23:21:47 -0000 On Sun, Mar 08, 2015 at 11:05:29PM +0000 I heard the voice of Steven Hartland, and lo! it spake thus: > > IIRC ufs doesn't support TRIM by default, it needs to be manually > enabled. But if you `newfs -t` it, and then mount on a stack that doesn't support TRIM, it notices and doesn't send any BIO_DELETE's. > GELI is kind of different though given is use, I'm sure users of it > would expect delete to leave no trace of the data which was there, > which is what I was under the impression it does, correct me if I'm > wrong? Oh, I see where you're coming from. No, there's a comment suggesting it could shred the data, but that's never been implemented. The current code just falls through to the default case of the switch and denies it: . case BIO_DELETE: . . /* . . * We could eventually support BIO_DELETE request. . . * It could be done by overwritting requested sector with . . * random data g_eli_overwrites number of times. . . */ . default: . . g_io_deliver(bp, EOPNOTSUPP); . . return; -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-geom@FreeBSD.ORG Sun Mar 8 23:48:59 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 2C9A9AFA for ; Sun, 8 Mar 2015 23:48:59 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 048D092C for ; Sun, 8 Mar 2015 23:48:58 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t28Nmp7k088376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Mar 2015 16:48:51 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t28NmpiH088375; Sun, 8 Mar 2015 16:48:51 -0700 (PDT) (envelope-from jmg) Date: Sun, 8 Mar 2015 16:48:51 -0700 From: John-Mark Gurney To: Steven Hartland Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150308234851.GA32329@funkthat.com> References: <20150308000131.GP1742@over-yonder.net> <54FC4E99.4080202@multiplay.co.uk> <20150308223552.GR1742@over-yonder.net> <54FCCFC3.4000007@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54FCCFC3.4000007@multiplay.co.uk> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Sun, 08 Mar 2015 16:48:52 -0700 (PDT) Cc: "Matthew D. Fuller" , 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 23:48:59 -0000 Steven Hartland wrote this message on Sun, Mar 08, 2015 at 22:40 +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. Considering that the upper layer will learn if it's supported or not, this is a minor issue... If an upper layer continues to issue _DELETE's after an EOPNOTSUPP error, then that's a different issue, and needs to be fixed there... > 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. Considering that you have to to enable it on your provider, I don't see a security issue... The patch documents this behavior... I don't see a "major" security issue w/ passing through _DELETE... Yes, on some devices, the data may be around for longer, but it is benifical on SSDs... If we wanted to be paranoid, we could write data before doing a _DELETE, but on SSDs that's just pointless... Provide the tools to the admin and document properly... I would say that the man page wording isn't complete... Maybe adding: Even after a sector has been deleted, it is possible that the data may still be readable depending upon how the underlying provider implements .Dv BIO_DELETE . BIO_DELETE should be used w/ .Dv. The date is not bumped... Even though it will be incorrect, it's useful to include to remind people that it needs to be done... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-geom@FreeBSD.ORG Tue Mar 10 01:44:37 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 0BAE61E6 for ; Tue, 10 Mar 2015 01:44:37 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E618431B for ; Tue, 10 Mar 2015 01:44:36 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2A1iafF039889 for ; Tue, 10 Mar 2015 01:44:36 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bug 198405] [PATCH] gnop: Count all BIO types Date: Tue, 10 Mar 2015 01:44:36 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-geom@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to component Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Tue, 10 Mar 2015 01:44:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198405 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-geom@FreeBSD.org Component|kern |bin -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-geom@FreeBSD.ORG Tue Mar 10 02:13:09 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 4DB40246 for ; Tue, 10 Mar 2015 02:13:09 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3387F952 for ; Tue, 10 Mar 2015 02:13:09 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2A2D9iI046947 for ; Tue, 10 Mar 2015 02:13:09 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bug 195683] [geli] geli boot passphrase prompt skips keys when newcons enabled, usb keyboard Date: Tue, 10 Mar 2015 02:13:08 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-geom@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Tue, 10 Mar 2015 02:13:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195683 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-geom@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-geom@FreeBSD.ORG Thu Mar 12 05:00:23 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 8E229AE7 for ; Thu, 12 Mar 2015 05:00:23 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 73C9C82A for ; Thu, 12 Mar 2015 05:00:23 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2C50NHo070084 for ; Thu, 12 Mar 2015 05:00:23 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bug 198500] [gjournal] sysctl kern.geom.journal.cache.limit 32 bit integer overflow Date: Thu, 12 Mar 2015 05:00:23 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-geom@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Thu, 12 Mar 2015 05:00:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198500 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-geom@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-geom@FreeBSD.ORG Thu Mar 12 05:11:04 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 03FAB3A9 for ; Thu, 12 Mar 2015 05:11:04 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DE6CE97B for ; Thu, 12 Mar 2015 05:11:03 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2C5B39t031411 for ; Thu, 12 Mar 2015 05:11:03 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bug 196834] geli setkey -P doesn't reset md_iterations Date: Thu, 12 Mar 2015 05:11:03 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-geom@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Thu, 12 Mar 2015 05:11:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196834 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-geom@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-geom@FreeBSD.ORG Thu Mar 12 05:12:37 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 F0B3F72B for ; Thu, 12 Mar 2015 05:12:37 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D6D94A42 for ; Thu, 12 Mar 2015 05:12:37 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2C5Cb7e063651 for ; Thu, 12 Mar 2015 05:12:37 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bug 196388] Gpart code violates EFI specification Date: Thu, 12 Mar 2015 05:12:38 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-geom@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Thu, 12 Mar 2015 05:12:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196388 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-geom@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-geom@FreeBSD.ORG Thu Mar 12 05:13:17 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 3916F82F for ; Thu, 12 Mar 2015 05:13:17 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1F0BFA59 for ; Thu, 12 Mar 2015 05:13:17 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2C5DGAU079364 for ; Thu, 12 Mar 2015 05:13:16 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bug 196241] gpart does not recognize Apple Core Storage partitions Date: Thu, 12 Mar 2015 05:13:17 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-geom@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Thu, 12 Mar 2015 05:13:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196241 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-geom@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-geom@FreeBSD.ORG Thu Mar 12 05:14:38 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 CC8CE9FD for ; Thu, 12 Mar 2015 05:14:38 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B2453A7E for ; Thu, 12 Mar 2015 05:14:38 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2C5EcN2000543 for ; Thu, 12 Mar 2015 05:14:38 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bug 183401] [bhyve] bhyve virtio-blk cannot be a raw disc device; bad GEOM interaction Date: Thu, 12 Mar 2015 05:14:38 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-virtualization@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Thu, 12 Mar 2015 05:14:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183401 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-virtualization@Free | |BSD.org CC| |freebsd-geom@FreeBSD.org -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-geom@FreeBSD.ORG Thu Mar 12 09:44:16 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 68C7FCFF for ; Thu, 12 Mar 2015 09:44:16 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4EBEAC02 for ; Thu, 12 Mar 2015 09:44:16 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2C9iGXb050508 for ; Thu, 12 Mar 2015 09:44:16 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bug 196241] gpart does not recognize Apple Core Storage partitions Date: Thu, 12 Mar 2015 09:44:16 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ae@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Thu, 12 Mar 2015 09:44:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196241 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-geom@FreeBSD.org |ae@FreeBSD.org CC| |ae@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-geom@FreeBSD.ORG Thu Mar 12 11:02:50 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 6042E713 for ; Thu, 12 Mar 2015 11:02:50 +0000 (UTC) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E944C74B for ; Thu, 12 Mar 2015 11:02:49 +0000 (UTC) Received: from [87.79.197.90] (helo=fabiankeil.de) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1YW0sz-0005uq-6J for freebsd-geom@freebsd.org; Thu, 12 Mar 2015 12:02:41 +0100 Date: Thu, 12 Mar 2015 12:02:40 +0100 From: Fabian Keil To: freebsd-geom@freebsd.org Subject: Re: RFC: Pass TRIM through GELI Message-ID: <7e0bacf0.308742dc@fabiankeil.de> In-Reply-To: <20150308000131.GP1742@over-yonder.net> References: <20150308000131.GP1742@over-yonder.net> Reply-To: freebsd-geom@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/6e20ukgblZR40Gx4QlS/MOi"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 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: Thu, 12 Mar 2015 11:02:50 -0000 --Sig_/6e20ukgblZR40Gx4QlS/MOi Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable "Matthew D. Fuller" wrote: > I've done a quick implementation of TRIM passthru support for GELI. Awesome, looks like my TODO list just got shorter. > Patch attached is against late Feb -CURRENT; however, a glance at svn > suggests this code hasn't changed much, so it's probably pretty > portable forward and back. It applies cleanly to a stable/10 tree > though I haven't tried compiling or using it there. >=20 > This has been lightly tested and seems to work fine. It adds a '-t' > flag to init and onetime to enable passthru on the new provider, and > '-t/-T' options to configure to en/disable on existing (but see caveat > below about metadata versions; as written, you can't use this on > existing partitions). >=20 > Since all we're doing is passing it through instead of denying it, I'd > expect "seems to work" to be pretty much the same as "does work"; the > requests go through, space clears up, and messing with a little ZFS on > top of it doesn't show up any data corruption. I tested it with ZFS below geli and the result was newfs hanging "unkillabl= e" after sending the first delete request (according to the patched gnop): fk@r500 ~ $sudo geli init -t /dev/zvol/tank/scratch/scratchvol.nop Enter new passphrase:=20 Reenter new passphrase:=20 Metadata backup can be found in /var/backups/zvol_tank_scratch_scratchvol.n= op.eli and can be restored with the following command: # geli restore /var/backups/zvol_tank_scratch_scratchvol.nop.eli /dev/zvol= /tank/scratch/scratchvol.nop fk@r500 ~ $sudo geli attach /dev/zvol/tank/scratch/scratchvol.nop Enter passphrase:=20 fk@r500 ~ $sudo newfs -E /dev/zvol/tank/scratch/scratchvol.nop.eli /dev/zvol/tank/scratch/scratchvol.nop.eli: 500.0MB (1023992 sectors) block = size 32768, fragment size 4096 using 4 cylinder groups of 125.00MB, 4000 blks, 16000 inodes. Erasing sectors [128...1023991] load: 0.26 cmd: newfs 1583 [gdelete] 104.74r 0.00u 0.01s 0% 2932k load: 0.20 cmd: newfs 1583 [gdelete] 206.48r 0.00u 0.01s 0% 2932k load: 0.23 cmd: newfs 1583 [gdelete] 1293.55r 0.00u 0.01s 0% 2932k [different terminal:] fk@r500 ~ $gnop list Geom name: zvol/tank/scratch/scratchvol.nop WroteBytes: 409852928 ReadBytes: 960000 Cmd2s: 0 Cmd1s: 0 Cmd0s: 0 Flushes: 2 Getattrs: 55 Deletes: 1 Writes: 3163 Reads: 207 Error: 5 WriteFailProb: 0 ReadFailProb: 0 Offset: 0 Providers: 1. Name: zvol/tank/scratch/scratchvol.nop Mediasize: 524288000 (500M) Sectorsize: 512 Mode: r1w1e1 Consumers: 1. Name: zvol/tank/scratch/scratchvol Mediasize: 524288000 (500M) Sectorsize: 512 Stripesize: 8192 Stripeoffset: 0 Mode: r1w1e1 fk@r500 ~ $sudo procstat -kk $(pgrep newfs) PID TID COMM TDNAME KSTACK = =20 1583 100072 newfs - mi_switch+0xde sleepq_wait+0= x3a _sleep+0x2c5 biowait+0xa0 g_delete_data+0x63 g_dev_ioctl+0x176 devfs_io= ctl_f+0x13b kern_ioctl+0x401 sys_ioctl+0x153 amd64_syscall+0x3e7 Xfast_sysc= all+0xfb=20 The gnop statistic above includes a previous test without geli init -t. > In this implementation, I added a new G_ELI_VERSION and required it > for setting the flag. I actually think this is probably not > necessary; all we do is set a value in the flags field, and if it's > loaded onto a system that doesn't know what to do with that value, > it'll just do nothing, which IMO is fine. And since there is no `geli > upgrade`, this means that you can't enable it on any existing > partitions, but have to kill/init from scratch, which isn't very > user-friendly. So I propose that it actually be done sans those > version changes, but they are in the patch as attached for now. I agree that a version bump doesn't seem necessary. Fabian --Sig_/6e20ukgblZR40Gx4QlS/MOi Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUBck0ACgkQBYqIVf93VJ0icwCdHzy2SGR44fQ3z9OJ2hQwo5ti oIEAn3qiu82aIfsAsynIO8U5jxyJlRjh =pv8p -----END PGP SIGNATURE----- --Sig_/6e20ukgblZR40Gx4QlS/MOi-- From owner-freebsd-geom@FreeBSD.ORG Thu Mar 12 18:25:33 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 52988D1D for ; Thu, 12 Mar 2015 18:25:33 +0000 (UTC) Received: from thyme.infocus-llc.com (thyme.infocus-llc.com [199.15.120.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1BDAC3BA for ; Thu, 12 Mar 2015 18:25:32 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 3902337B66E for ; Thu, 12 Mar 2015 13:25:31 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3l2z9Q40X0z1fK; Thu, 12 Mar 2015 13:25:30 -0500 (CDT) Date: Thu, 12 Mar 2015 13:25:30 -0500 From: "Matthew D. Fuller" To: freebsd-geom@freebsd.org Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150312182530.GF24274@over-yonder.net> References: <20150308000131.GP1742@over-yonder.net> <7e0bacf0.308742dc@fabiankeil.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7e0bacf0.308742dc@fabiankeil.de> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.23-fullermd.4 (2014-03-12) X-Virus-Scanned: clamav-milter 0.98.6 at thyme.infocus-llc.com X-Virus-Status: Clean 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: Thu, 12 Mar 2015 18:25:33 -0000 On Thu, Mar 12, 2015 at 12:02:40PM +0100 I heard the voice of Fabian Keil, and lo! it spake thus: > > I tested it with ZFS below geli and the result was newfs hanging > "unkillable" after sending the first delete request (according to > the patched gnop): That is interesting. gstat seems to show an outstanding request down to the zvol, but not beyond: L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 0 0 0 0 0.0 0 0 0.0 0.0| ada0s1 1 0 0 0 0.0 0 0 0.0 0.0| zvol/t/tvol 1 0 0 0 0.0 0 0 0.0 0.0| zvol/t/tvol.eli Pool 't' created on ada0s1, zvol 'tvol' created, 'onetime -e NULL -t' geli on top of that, newfs -E'd. In this case, ada0 wouldn't support TRIM anyway, but I get identical results doing it on a md(4) that would. Doesn't seem to happen the other way around (zvol on zpool on .eli). Or, in a handful of tests, on anything I can make not a zvol... Little investigation attempt: if I set kern.geom.debugflags=2 and do a newfs on the zvol/t/tvol (if I'm reading this right), the BIO_DELETE goes in and comes right out: Mar 12 12:32:49 netboot-current kernel: bio_request(0xfffff80004d42ba0) from 0xfffff80004cff400(zvol/t/tvol) to 0xfffff800041fc300(zvol/t/tvol) cmd 4 Mar 12 12:32:49 netboot-current kernel: g_io_deliver(0xfffff80004d42ba0) from 0xfffff80004cff400(zvol/t/tvol) to 0xfffff800041fc300(zvol/t/tvol) cmd 4 error 0 off 65536 len 104792064 (then there's a read, and a buncha writes) On the zvol/t/tvol.eli, though, the BIO_DELETE goes through the tvol.eli to the tvol, and then... does nothing: Mar 12 12:33:24 netboot-current kernel: bio_request(0xfffff800041991f0) from 0xfffff800491a7e80(zvol/t/tvol.eli) to 0xfffff800041fb600(zvol/t/tvol.eli) cmd 4 Mar 12 12:33:24 netboot-current kernel: bio_request(0xfffff80004d42ba0) from 0xfffff800491a7f00(zvol/t/tvol.eli) to 0xfffff800041fc300(zvol/t/tvol) cmd 4 (nothing happens for 5 seconds, and then there're some writes between zfs::vdev and ada0s1, which I presume are the flushes of the writes that happen before the _DELETE is attempted. No further 'cmd 4's show up in the log, at least for the couple minutes 'till I rebooted.) What if we build a .nop on the tvol? Mar 12 12:47:30 netboot-current kernel: bio_request(0xfffff800041c0c98) from 0xfffff80002ab0780(zvol/t/tvol.nop) to 0xfffff8004910fe00(zvol/t/tvol.nop) cmd 4 Mar 12 12:47:30 netboot-current kernel: bio_request(0xfffff800041b36c8) from 0xfffff80002ab0800(zvol/t/tvol.nop) to 0xfffff80002862100(zvol/t/tvol) cmd 4 [ ... couple lines of other requests elided ... ] Mar 12 12:47:31 netboot-current kernel: g_io_deliver(0xfffff800041b36c8) from 0xfffff80002ab0800(zvol/t/tvol.nop) to 0xfffff80002862100(zvol/t/tvol) cmd 4 error 0 off 65536 len 104792064 Mar 12 12:47:31 netboot-current kernel: g_io_deliver(0xfffff800041c0c98) from 0xfffff80002ab0780(zvol/t/tvol.nop) to 0xfffff8004910fe00(zvol/t/tvol.nop) cmd 4 error 0 off 65536 len 104792064 Well, so that starts out just the same as the .eli case, but it gets a response back. .eli on a md? Clean too. Mar 12 13:05:28 netboot-current kernel: bio_request(0xfffff800041b35d0) from 0xfffff800672fce80(md2s1.eli) to 0xfffff8004910f000(md2s1.eli) cmd 4 Mar 12 13:05:28 netboot-current kernel: bio_request(0xfffff800041c17c0) from 0xfffff800672fce00(md2s1.eli) to 0xfffff8004910fe00(md2s1) cmd 4 Mar 12 13:05:28 netboot-current kernel: g_part_start: cmd=4, provider=md2s1 Mar 12 13:05:28 netboot-current kernel: bio_request(0xfffff80004c8eba0) from 0xfffff80002886e80(md2) to 0xfffff800044e1600(md2) cmd 4 Mar 12 13:05:31 netboot-current kernel: g_io_deliver(0xfffff80004c8eba0) from 0xfffff80002886e80(md2) to 0xfffff800044e1600(md2) cmd 4 error 0 off 90112 len 104747008 Mar 12 13:05:31 netboot-current kernel: g_io_deliver(0xfffff800041c17c0) from 0xfffff800672fce00(md2s1.eli) to 0xfffff8004910fe00(md2s1) cmd 4 error 0 off 65536 len 104747008 Mar 12 13:05:31 netboot-current kernel: g_io_deliver(0xfffff800041b35d0) from 0xfffff800672fce80(md2s1.eli) to 0xfffff8004910f000(md2s1.eli) cmd 4 error 0 off 65536 len 104747008 Not telling me much... -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-geom@FreeBSD.ORG Thu Mar 12 19:51:12 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 ACD44766 for ; Thu, 12 Mar 2015 19:51:12 +0000 (UTC) Received: from thyme.infocus-llc.com (thyme.infocus-llc.com [199.15.120.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 85982F75 for ; Thu, 12 Mar 2015 19:51:12 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 4AA8937B5AB for ; Thu, 12 Mar 2015 14:51:10 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3l314F4yNdz1kd; Thu, 12 Mar 2015 14:51:09 -0500 (CDT) Date: Thu, 12 Mar 2015 14:51:09 -0500 From: "Matthew D. Fuller" To: freebsd-geom@freebsd.org Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150312195109.GG24274@over-yonder.net> References: <20150308000131.GP1742@over-yonder.net> <7e0bacf0.308742dc@fabiankeil.de> <20150312182530.GF24274@over-yonder.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150312182530.GF24274@over-yonder.net> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.23-fullermd.4 (2014-03-12) X-Virus-Scanned: clamav-milter 0.98.6 at thyme.infocus-llc.com X-Virus-Status: Clean 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: Thu, 12 Mar 2015 19:51:12 -0000 > Little investigation attempt: Looking a little further, it seems like that BIO_DELETE is never getting into zvol_strategy(). Piling on debug, when newfs'ing directly on the zvol, we enter zvol_geom_start() with the BIO_DELETE, it drops into the case in the early switch, and passes the bp down to zvol_strategy(). No problem. When newfs'ing on the .eli, it enters the if (!THREAD_CAN_SLEEP()), which jumps ahead to some a bioq_insert_tail(), into an empty bioq, falls into the if(first) block and calls wakeup_one(), and then falls off the end and returns from zvol_geom_start(). And that's the end of the line; nothing else ever happens. So, either the zvol isn't actually firing off the event right, or we need to do something more complicated with BIO_DELETE than we do with _GETATTR and _FLUSH. I couldn't really say which... -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-geom@FreeBSD.ORG Fri Mar 13 02:50:35 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 7059FC2C; Fri, 13 Mar 2015 02:50:35 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B7998E2; Fri, 13 Mar 2015 02:50:34 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t2D2oXEL063475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2015 19:50:33 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t2D2oX3M063474; Thu, 12 Mar 2015 19:50:33 -0700 (PDT) (envelope-from jmg) Date: Thu, 12 Mar 2015 19:50:33 -0700 From: John-Mark Gurney To: "Matthew D. Fuller" Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150313025032.GJ32288@funkthat.com> References: <20150308000131.GP1742@over-yonder.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150308000131.GP1742@over-yonder.net> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Thu, 12 Mar 2015 19:50:33 -0700 (PDT) Cc: pjd@freebsd.org, 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: Fri, 13 Mar 2015 02:50:35 -0000 Matthew D. Fuller wrote this message on Sat, Mar 07, 2015 at 18:01 -0600: > [ bcc'd to -fs because it's been discussed there in the past; followup > to -geom because that seems where it belongs ] > > I've done a quick implementation of TRIM passthru support for GELI. > Patch attached is against late Feb -CURRENT; however, a glance at svn > suggests this code hasn't changed much, so it's probably pretty > portable forward and back. It applies cleanly to a stable/10 tree > though I haven't tried compiling or using it there. > > This has been lightly tested and seems to work fine. It adds a '-t' > flag to init and onetime to enable passthru on the new provider, and > '-t/-T' options to configure to en/disable on existing (but see caveat > below about metadata versions; as written, you can't use this on > existing partitions). > > Since all we're doing is passing it through instead of denying it, I'd > expect "seems to work" to be pretty much the same as "does work"; the > requests go through, space clears up, and messing with a little ZFS on > top of it doesn't show up any data corruption. > > The patch to gnop in > is a useful > adjunct in checking when/if the requests actually go through, by > making the .eli on top of the .nop and seeing when the counters tick. > > > In this implementation, I added a new G_ELI_VERSION and required it > for setting the flag. I actually think this is probably not > necessary; all we do is set a value in the flags field, and if it's > loaded onto a system that doesn't know what to do with that value, > it'll just do nothing, which IMO is fine. And since there is no `geli > upgrade`, this means that you can't enable it on any existing > partitions, but have to kill/init from scratch, which isn't very > user-friendly. So I propose that it actually be done sans those > version changes, but they are in the patch as attached for now. > > > One not-quite-related change in here is that I added a denial for > 'geli configure' attempts on onetime providers. Trying this causes a > panic, as the metadata version field on onetime providers is > nonsensical. As far as I can tell in quick testing, this isn't > related to my changes; it happens with stock GELI code as well. > Presumably it's never been noticed before since the only prior use for > 'geli configure' was to un/set the BOOT flag, which makes no sense on > a onetime anyway, so nobody ever bothered trying. But with -[tT], > somebody might try. Evidence: I did, and found the panic :) Oh, it looks like we have a flag to show if a provider can delete, see: svnweb.freebsd.org/changeset/base/r279913 -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-geom@FreeBSD.ORG Sat Mar 14 15:01:43 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 71D29CF3; Sat, 14 Mar 2015 15:01:43 +0000 (UTC) Received: from thyme.infocus-llc.com (thyme.infocus-llc.com [199.15.120.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49B1CC64; Sat, 14 Mar 2015 15:01:42 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 5892F37B407; Sat, 14 Mar 2015 10:01:36 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3l46YC4nhBz2hf; Sat, 14 Mar 2015 10:01:35 -0500 (CDT) Date: Sat, 14 Mar 2015 10:01:35 -0500 From: "Matthew D. Fuller" To: John-Mark Gurney Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150314150135.GI24274@over-yonder.net> References: <20150308000131.GP1742@over-yonder.net> <20150313025032.GJ32288@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150313025032.GJ32288@funkthat.com> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.23-fullermd.4 (2014-03-12) X-Virus-Scanned: clamav-milter 0.98.6 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: pjd@freebsd.org, 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: Sat, 14 Mar 2015 15:01:43 -0000 On Thu, Mar 12, 2015 at 07:50:33PM -0700 I heard the voice of John-Mark Gurney, and lo! it spake thus: > > Oh, it looks like we have a flag to show if a provider can delete, GELI is transparent to GETATTR requests, so anything asking it will get the answer from the underlying provider. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-geom@FreeBSD.ORG Sat Mar 14 15:14:54 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 EC18FF79 for ; Sat, 14 Mar 2015 15:14:54 +0000 (UTC) Received: from thyme.infocus-llc.com (thyme.infocus-llc.com [199.15.120.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C50C5D47 for ; Sat, 14 Mar 2015 15:14:54 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 0626837B4E5 for ; Sat, 14 Mar 2015 10:14:54 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3l46rY3Xz6z2hx; Sat, 14 Mar 2015 10:14:53 -0500 (CDT) Date: Sat, 14 Mar 2015 10:14:53 -0500 From: "Matthew D. Fuller" To: freebsd-geom@freebsd.org Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150314151453.GJ24274@over-yonder.net> References: <20150308000131.GP1742@over-yonder.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150308000131.GP1742@over-yonder.net> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.23-fullermd.4 (2014-03-12) X-Virus-Scanned: clamav-milter 0.98.6 at thyme.infocus-llc.com X-Virus-Status: Clean 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: Sat, 14 Mar 2015 15:14:55 -0000 > I've done a quick implementation of TRIM passthru support for GELI. Here's a slightly updated version. Some adjustments to the manpage suggested by jmg@, and I've stripped out the new version and checks for it. Should be functionally the same as the prior, with the exception of the version checks. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-geom@FreeBSD.ORG Sat Mar 14 16:38:24 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 46B64EDD for ; Sat, 14 Mar 2015 16:38:24 +0000 (UTC) Received: from thyme.infocus-llc.com (thyme.infocus-llc.com [199.15.120.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1DA316AB for ; Sat, 14 Mar 2015 16:38:23 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 5288037B54F for ; Sat, 14 Mar 2015 11:38:23 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3l48ht5ly3z2jy; Sat, 14 Mar 2015 11:38:22 -0500 (CDT) Date: Sat, 14 Mar 2015 11:38:22 -0500 From: "Matthew D. Fuller" To: freebsd-geom@freebsd.org Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150314163822.GL24274@over-yonder.net> References: <20150308000131.GP1742@over-yonder.net> <7e0bacf0.308742dc@fabiankeil.de> <20150312182530.GF24274@over-yonder.net> <20150312195109.GG24274@over-yonder.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150312195109.GG24274@over-yonder.net> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.23-fullermd.4 (2014-03-12) X-Virus-Scanned: clamav-milter 0.98.6 at thyme.infocus-llc.com X-Virus-Status: Clean 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: Sat, 14 Mar 2015 16:38:24 -0000 > I couldn't really say which... My conclusion is that this is a zvol bug. With the patch in , it all seems to work fine. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-geom@FreeBSD.ORG Sat Mar 14 17:43:35 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 0D695C0E for ; Sat, 14 Mar 2015 17:43:35 +0000 (UTC) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (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 9951CCDF for ; Sat, 14 Mar 2015 17:43:34 +0000 (UTC) Received: by wibdy8 with SMTP id dy8so9457545wib.0 for ; Sat, 14 Mar 2015 10:43:32 -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=oDeJGpjuRxfWuhRHlFUbL2mmHQDfvYN3troZX3gwICY=; b=E0/V/mFy9LOqkiCdsetoJOEooEjSSST59d4a1qZL9kfP06KJANB0sK84D4B0Fl1vtn DxvLF1rxbTEnzYnGt90Fk+qV55uKwce8915oJ2Sl0+TExkgGdO7kfXZEEPwF0mo1MF+Z 4LYLAhcDboEnRc+E7Ly2BNdEJ48Sa6od0oAapvEDU+DNlvOb/tokjYBxnFPCMUMGAUCZ cxB0ER1h/1bFaLizJruHzmRXhvIKbCt8wdahaULX1uSydQBSQxsO+zARA3Cxm/pobgKy WxLL3o4QgQVWZ9blW1ucOdLWFxjnosrNgazB6icG+tjBdTwwwHxvdO6h9vPLX95tur8j Nx1Q== X-Gm-Message-State: ALoCoQn9CCRurNZQdnztLZ9NRhR3q60gwiYuPH1qNqoQg0XArrRux5To0FFbxTWtHVbvoDZM5iUZ X-Received: by 10.180.74.170 with SMTP id u10mr31898504wiv.46.1426354706751; Sat, 14 Mar 2015 10:38:26 -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 v8sm3419494wib.0.2015.03.14.10.38.25 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Mar 2015 10:38:25 -0700 (PDT) Message-ID: <5504720A.2000703@multiplay.co.uk> Date: Sat, 14 Mar 2015 17:38:18 +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> <7e0bacf0.308742dc@fabiankeil.de> <20150312182530.GF24274@over-yonder.net> <20150312195109.GG24274@over-yonder.net> <20150314163822.GL24274@over-yonder.net> In-Reply-To: <20150314163822.GL24274@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: Sat, 14 Mar 2015 17:43:35 -0000 On 14/03/2015 16:38, Matthew D. Fuller wrote: >> I couldn't really say which... > My conclusion is that this is a zvol bug. With the patch in > , > it all seems to work fine. > Correct, committed: https://svnweb.freebsd.org/changeset/base/279996