From owner-freebsd-geom@FreeBSD.ORG Sun Mar 15 09:09: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 35E87C77 for ; Sun, 15 Mar 2015 09:09: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 1A92138B for ; Sun, 15 Mar 2015 09:09: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 t2F99bEB048429 for ; Sun, 15 Mar 2015 09:09:37 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bug 197309] ggatec has been broken since rev 238119 Date: Sun, 15 Mar 2015 09:09:37 +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.0-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ota@j.email.ne.jp 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: attachments.created 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: Sun, 15 Mar 2015 09:09:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197309 --- Comment #2 from ota@j.email.ne.jp --- Created attachment 154318 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=154318&action=edit server side reproduce procedure I captured ggated configuration and steps by 'script.' Once ggated is started, run "ggatec create -o rw 127.0.0.1 /dev/md1" on another terminal. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-geom@FreeBSD.ORG Sun Mar 15 10:24:11 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 D6F81D9B for ; Sun, 15 Mar 2015 10:24:11 +0000 (UTC) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.103]) (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 93146CBF for ; Sun, 15 Mar 2015 10:24:11 +0000 (UTC) Received: from [87.79.196.203] (helo=fabiankeil.de) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1YX5iE-0006Ut-TQ for freebsd-geom@freebsd.org; Sun, 15 Mar 2015 11:24:02 +0100 Date: Sun, 15 Mar 2015 11:24:03 +0100 From: Fabian Keil To: freebsd-geom@freebsd.org Subject: Re: RFC: Pass TRIM through GELI Message-ID: <501bca86.508d8e26@fabiankeil.de> In-Reply-To: <20150314151453.GJ24274@over-yonder.net> References: <20150308000131.GP1742@over-yonder.net> <20150314151453.GJ24274@over-yonder.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/nNyi7q91bdbUcrQB5QG7+Ze"; 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: Sun, 15 Mar 2015 10:24:11 -0000 --Sig_/nNyi7q91bdbUcrQB5QG7+Ze 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. >=20 > 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. >=20 > Awesome. With a kernel based on r279996 the deletes make it to the zvol and zfs list confirms that the space is marked as free. ZFS on GELI on zvol works as expected as well. Additional testing revealed a NULL pointer dereference: http://www.fabiankeil.de/sourcecode/electrobsd/g_eli_ctl_onetime-Fix-NULL-p= ointer-dereference.diff Fabian --Sig_/nNyi7q91bdbUcrQB5QG7+Ze Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUFXb8ACgkQBYqIVf93VJ33tQCfZUIG+UNrwU3JHbOYEGNQBBW3 abkAnRY022PioZ6KzlIUc3EnWSYf/88p =I5Tk -----END PGP SIGNATURE----- --Sig_/nNyi7q91bdbUcrQB5QG7+Ze-- From owner-freebsd-geom@FreeBSD.ORG Sun Mar 15 14:53:27 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 651019E5 for ; Sun, 15 Mar 2015 14:53:27 +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 3C8ACB76 for ; Sun, 15 Mar 2015 14:53:26 +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 5C36837B402; Sun, 15 Mar 2015 09:53:25 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3l4kKJ5Ptkz36K; Sun, 15 Mar 2015 09:53:24 -0500 (CDT) Date: Sun, 15 Mar 2015 09:53:24 -0500 From: "Matthew D. Fuller" To: Fabian Keil Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150315145324.GA52331@over-yonder.net> References: <20150308000131.GP1742@over-yonder.net> <20150314151453.GJ24274@over-yonder.net> <501bca86.508d8e26@fabiankeil.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <501bca86.508d8e26@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 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, 15 Mar 2015 14:53:27 -0000 On Sun, Mar 15, 2015 at 11:24:03AM +0100 I heard the voice of Fabian Keil, and lo! it spake thus: > > Additional testing revealed a NULL pointer dereference: > http://www.fabiankeil.de/sourcecode/electrobsd/g_eli_ctl_onetime-Fix-NULL-pointer-dereference.diff Whoops. Well, that was dumber than usual of me :) -- 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 15 18:24:53 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 E077D90B for ; Sun, 15 Mar 2015 18:24:53 +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 B7B6F13C for ; Sun, 15 Mar 2015 18:24:53 +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 C664A37B5E4 for ; Sun, 15 Mar 2015 13:24:45 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3l4q190Dt7z6h; Sun, 15 Mar 2015 13:24:45 -0500 (CDT) Date: Sun, 15 Mar 2015 13:24:45 -0500 From: "Matthew D. Fuller" To: freebsd-geom@freebsd.org Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150315182444.GB52331@over-yonder.net> References: <20150308000131.GP1742@over-yonder.net> <20150314151453.GJ24274@over-yonder.net> <501bca86.508d8e26@fabiankeil.de> <20150315145324.GA52331@over-yonder.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150315145324.GA52331@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, 15 Mar 2015 18:24:54 -0000 > Whoops. Well, that was dumber than usual of me :) now includes that fix. -- 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 Mon Mar 16 01:11:39 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 E9B3CD15 for ; Mon, 16 Mar 2015 01:11:39 +0000 (UTC) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id B1F471F6 for ; Mon, 16 Mar 2015 01:11:38 +0000 (UTC) Received: from localhost (unknown [91.206.210.241]) by mail.dawidek.net (Postfix) with ESMTPSA id 7ECF2D16; Mon, 16 Mar 2015 02:05:56 +0100 (CET) Date: Mon, 16 Mar 2015 02:08:45 +0100 From: Pawel Jakub Dawidek To: "Matthew D. Fuller" Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150316010845.GA1515@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150315182444.GB52331@over-yonder.net> 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 01:11:40 -0000 On Sun, Mar 15, 2015 at 01:24:45PM -0500, Matthew D. Fuller wrote: > > Whoops. Well, that was dumber than usual of me :) > > > > now includes that fix. 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. Few small nits inline. --- sbin/geom/class/eli/geli.8 (revision 279210) +++ sbin/geom/class/eli/geli.8 (working copy) [...] +It will, however, provide some information (how much space you're actually I've been told some time ago that one should use 'you are', etc. in manual pages. --- sbin/geom/class/eli/geom_eli.c (revision 279210) +++ sbin/geom/class/eli/geom_eli.c (working copy) [...] + if(changed) Missing space after 'if'. --- sys/geom/eli/g_eli.c (revision 279210) +++ sys/geom/eli/g_eli.c (working copy) @@ -314,8 +314,11 @@ /* * We could eventually support BIO_DELETE request. * It could be done by overwritting requested sector with - * random data g_eli_overwrites number of times. + * random data g_eli_overwrites number of times. Or if the user + * has set the DELETE flag, we just pass it down the stack. This whole comment needs to be rewritten. In the current form it is not obvious if we support BIO_DELETE in any way or not. I'd start with what we got and add a note at the end what might be the other way to handle BIO_DELETE. --- sys/geom/eli/g_eli.h (revision 279210) +++ sys/geom/eli/g_eli.h (working copy) @@ -94,6 +94,8 @@ #define G_ELI_FLAG_AUTH 0x00000010 /* Provider is read-only, we should deny all write attempts. */ #define G_ELI_FLAG_RO 0x00000020 +/* Pass through BIO_DELETE requests */ Missing period at the end of the sentence. --- sys/geom/eli/g_eli_ctl.c (revision 279210) +++ sys/geom/eli/g_eli_ctl.c (working copy) @@ -377,11 +384,13 @@ char param[16]; const char *prov; u_char *sector; - int *nargs, *boot, *noboot; + int *nargs, *boot, *noboot, *trim, *notrim; int error; + int changed; Feel free to merge it with 'int error'. g_topology_assert(); + changed = 0; Please add an empty line to separate assertion from the initialization. + if (sc->sc_flags & G_ELI_FLAG_ONETIME) { + gctl_error(req, "Cannot change configuration of " + "onetime provider %s.", prov); + continue; + } Actually, nothing stops us from allowing to change trim/notrim for one-time providers. It is just we had no options before that would make sense for those kind of providers. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com From owner-freebsd-geom@FreeBSD.ORG Mon Mar 16 09:21:28 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 A09F996A; Mon, 16 Mar 2015 09:21:28 +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 76DAEDA9; Mon, 16 Mar 2015 09:21:28 +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 A356D37B54F; Mon, 16 Mar 2015 04:21:26 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3l5Bvp0hJczbB; Mon, 16 Mar 2015 04:21:26 -0500 (CDT) Date: Mon, 16 Mar 2015 04:21:26 -0500 From: "Matthew D. Fuller" To: Pawel Jakub Dawidek Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150316092126.GC52331@over-yonder.net> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150316010845.GA1515@garage.freebsd.pl> 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: Mon, 16 Mar 2015 09:21:28 -0000 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... > Few small nits inline. Thanks, addressed in geli-delete.4.patch. > I've been told some time ago that one should use 'you are', etc. in > manual pages. Rewrote away from the 2nd person, avoiding the issue entirely. > This whole comment needs to be rewritten. How about: /* * If the user has set the DELETE flag, we just pass it * down the stack and let the layers beneath us do (or * not) whatever they do with it. Else we currently just * reject it. A possible extension would be to take it * as a hint to shred the data with [multiple?] * overwrites. */ > + if (sc->sc_flags & G_ELI_FLAG_ONETIME) { > + gctl_error(req, "Cannot change configuration of " > + "onetime provider %s.", prov); > + continue; > + } > > Actually, nothing stops us from allowing to change trim/notrim for > one-time providers. Well, what stops us right now is the bit where it somehow finds metadata version 2468898832 when it tries, and then panics :(. It happened with both my changes and the existing code, so I figured it was just an artifact of something onetime did, and nobody ever cared (or tried) configure'ing one. In a quick re-test, I actually can't trigger it on a bare device, but on top of gnop it happens every time (with both original and my code). Nothing special, just an arg-less nop, and an arg-less onetime we 'configure -b' afterward. That makes it a little more concerning... I guess it needs more looking into; 0'd out the conditional in the .4.patch pending more investigation. -- 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 Mon Mar 16 09:57:45 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 933613B8 for ; Mon, 16 Mar 2015 09:57:45 +0000 (UTC) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 59F3D16B for ; Mon, 16 Mar 2015 09:57:44 +0000 (UTC) Received: from localhost (unknown [91.206.210.241]) by mail.dawidek.net (Postfix) with ESMTPSA id 8412DDEC; Mon, 16 Mar 2015 10:57:42 +0100 (CET) Date: Mon, 16 Mar 2015 11:00:31 +0100 From: Pawel Jakub Dawidek To: "Matthew D. Fuller" Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150316100030.GB1515@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150316092126.GC52331@over-yonder.net> 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 09:57:45 -0000 On Mon, Mar 16, 2015 at 04:21:26AM -0500, 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... You are right. I read your reasoning you've sent earlier after sending my e-mail. > > This whole comment needs to be rewritten. > > How about: > > /* > * If the user has set the DELETE flag, we just pass it > * down the stack and let the layers beneath us do (or > * not) whatever they do with it. Else we currently just > * reject it. A possible extension would be to take it > * as a hint to shred the data with [multiple?] > * overwrites. > */ Looks good, thanks. > > + if (sc->sc_flags & G_ELI_FLAG_ONETIME) { > > + gctl_error(req, "Cannot change configuration of " > > + "onetime provider %s.", prov); > > + continue; > > + } > > > > Actually, nothing stops us from allowing to change trim/notrim for > > one-time providers. > > Well, what stops us right now is the bit where it somehow finds > metadata version 2468898832 when it tries, and then panics :(. It > happened with both my changes and the existing code, so I figured it > was just an artifact of something onetime did, and nobody ever cared > (or tried) configure'ing one. > > In a quick re-test, I actually can't trigger it on a bare device, but > on top of gnop it happens every time (with both original and my code). > Nothing special, just an arg-less nop, and an arg-less onetime we > 'configure -b' afterward. That makes it a little more concerning... > I guess it needs more looking into; 0'd out the conditional in the > .4.patch pending more investigation. Rejecting -b/-B for one-time providers is of course fine. Accepting -t/-T for one-time providers would be nice to have, but of course nothing critical. Still would be good to know the root cause of what you are seeing. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com From owner-freebsd-geom@FreeBSD.ORG Mon Mar 16 10:13:25 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 428B16A2; Mon, 16 Mar 2015 10:13:25 +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 17CF335A; Mon, 16 Mar 2015 10:13:24 +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 AC24737B568; Mon, 16 Mar 2015 05:13:23 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3l5D3l15CPzc6; Mon, 16 Mar 2015 05:13:23 -0500 (CDT) Date: Mon, 16 Mar 2015 05:13:23 -0500 From: "Matthew D. Fuller" To: Pawel Jakub Dawidek Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150316101323.GD52331@over-yonder.net> 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> <20150316100030.GB1515@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150316100030.GB1515@garage.freebsd.pl> 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: Mon, 16 Mar 2015 10:13:25 -0000 On Mon, Mar 16, 2015 at 11:00:31AM +0100 I heard the voice of Pawel Jakub Dawidek, and lo! it spake thus: > > Still would be good to know the root cause of what you are seeing. I've about used up my investigation time for right now, but what I've found is that onetime providers wind up with no md_magic and no (0) md_version, so eli_metadata_decode() EINVAL's right up at the top before filling anything into the passed md. As a result, in g_eli_ctl_configure(), it gets (keeps) stack garbage in the var. So actually, it DOESN'T work without nop, things just happen to align so that stack garbage has a 0 for version (which is valid version) rather than 2-billion-something (which isn't). Now, regular providers get init'd in userland, so it's hard to compare. However, my current thinking is that onetime does much of what 'geli attach' does, but not all of what 'geli init' does; it doesn't ever write out the metadata to the provider since it doesn't need to persist. But when configure wants to load the metadata, it takes it from the provider, and so *boom*. -- 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 Mon Mar 16 10:14:57 2015 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B08A72D for ; Mon, 16 Mar 2015 10:14:57 +0000 (UTC) Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A630379 for ; Mon, 16 Mar 2015 10:14:56 +0000 (UTC) Received: by weop45 with SMTP id p45so8965872weo.0 for ; Mon, 16 Mar 2015 03:14:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dM57sNrvcOpmCb5hLXcBvc0Wbk7CD4HOXgmsEPCwXIU=; b=UL2LHlAOPeppSXVb41S27n7VUydV9djToKsbeG1aqs1SEuZfqJ1w8F7pqtuyjH2hfD sXq1o62eQGDFLPseZpV5szz7DpPXyBl2DTxMC++CT7OD9gko4j22L/6SXKH6v4tRQal8 +nAUeyPR8FghlA219F+ErLbGwXyAA3GDTcK8tvyTI2m9FAfyauRPrVI9QeAL0WM+WSUV c6LupIiE5PpiCxFIk9aVIJYuKovoozK5o4hMMAYXpu3MvsGSiaqJFJIsEcqLPTxWqRsC xOLGjrGPsHGO6Uf/bssitIRFoGtc/KcWXYhc8SlqTFuFMhM1zF5E7FRMlQYvXY8Wj+AN hLhg== X-Gm-Message-State: ALoCoQlq2UmHdG8qjvCrdm94BhWQ7+9ODpjczMPs2aExQ+IovS1inmO1per4qCO0zt8RCCQ+26EX X-Received: by 10.194.86.194 with SMTP id r2mr123820617wjz.41.1426500889355; Mon, 16 Mar 2015 03:14:49 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id fm10sm14666280wib.7.2015.03.16.03.14.47 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Mar 2015 03:14:47 -0700 (PDT) Message-ID: <5506AD12.2090603@multiplay.co.uk> Date: Mon, 16 Mar 2015 10:14:42 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-geom@freebsd.org Subject: Re: RFC: Pass TRIM through GELI References: <20150308000131.GP1742@over-yonder.net> <20150314151453.GJ24274@over-yonder.net> <501bca86.508d8e26@fabiankeil.de> <20150315145324.GA52331@over-yonder.net> <20150315182444.GB52331@over-yonder.net> <20150316010845.GA1515@garage.freebsd.pl> <20150316092126.GC52331@over-yonder.net> In-Reply-To: <20150316092126.GC52331@over-yonder.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 10:14:57 -0000 On 16/03/2015 09:21, Matthew D. Fuller wrote: > On Mon, Mar 16, 2015 at 02:08:45AM +0100 I heard the voice of > Pawel Jakub Dawidek, and lo! it spake thus: >> Overall the patch looks good. The main concern I have is that we do >> nothing if the underlying provider returns EOPNOTSUPP on BIO_DELETE, >> we will just keep sending those requests. > Well, they're all coming from the layer above us, and it'll get back > the EOPNOTSUPP's, so if it keeps sending them anyway that seems more > like its problem than ours. It seems like intercepting the response > (that would mean making our own new request, getting the response, > then making that response ourselves to the original?) wouldn't really > save much of anything, and adds a lot of extra bug-havens... > See how ZFS details with this, it adds internal state to the device which stores and bypasses the pass down after the first EOPNOTSUPP. This avoids the full stack round trip, which when volumes of deletes are high could be noticeable. Regards Steve From owner-freebsd-geom@FreeBSD.ORG Mon Mar 16 10:18:45 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 44EC1959; Mon, 16 Mar 2015 10:18:45 +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 19D263E0; Mon, 16 Mar 2015 10:18:44 +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 048C637B568; Mon, 16 Mar 2015 05:18:44 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3l5D9v3xdhzcJ; Mon, 16 Mar 2015 05:18:43 -0500 (CDT) Date: Mon, 16 Mar 2015 05:18:43 -0500 From: "Matthew D. Fuller" To: Pawel Jakub Dawidek Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150316101843.GE52331@over-yonder.net> 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> <20150316100030.GB1515@garage.freebsd.pl> <20150316101323.GD52331@over-yonder.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150316101323.GD52331@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 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 10:18:45 -0000 On Mon, Mar 16, 2015 at 05:13:23AM -0500 I heard the voice of Matthew D. Fuller, and lo! it spake thus: > > , so eli_metadata_decode() EINVAL's right up at the top before > filling anything into the passed md. As a result, in > g_eli_ctl_configure(), it gets (keeps) stack garbage in the var. As a side note, this seems to turn from "darn" to "panic" because in g_eli_read_metadata(), it doesn't check the return from eli_metadata_decode(), so it doesn't notice the EINVAL and happily reports back success without ever having touched the md :( -- 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 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 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. From owner-freebsd-geom@FreeBSD.ORG Mon Mar 16 14:22:00 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 980E8F5D for ; Mon, 16 Mar 2015 14:22:00 +0000 (UTC) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.29]) (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 5275F87F for ; Mon, 16 Mar 2015 14:21:59 +0000 (UTC) Received: from [87.79.198.241] (helo=fabiankeil.de) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1YXVqA-0006xV-HD for freebsd-geom@freebsd.org; Mon, 16 Mar 2015 15:17:58 +0100 Date: Mon, 16 Mar 2015 15:17:58 +0100 From: Fabian Keil To: freebsd-geom@freebsd.org Subject: Re: RFC: Pass TRIM through GELI Message-ID: <3d5629f4.63dcb347@fabiankeil.de> In-Reply-To: <20150316101323.GD52331@over-yonder.net> 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> <20150316100030.GB1515@garage.freebsd.pl> <20150316101323.GD52331@over-yonder.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/duOBSR7HPL.IQWZK4+m/pIr"; 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: Mon, 16 Mar 2015 14:22:00 -0000 --Sig_/duOBSR7HPL.IQWZK4+m/pIr Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable "Matthew D. Fuller" wrote: > On Mon, Mar 16, 2015 at 11:00:31AM +0100 I heard the voice of > Pawel Jakub Dawidek, and lo! it spake thus: > > > > Still would be good to know the root cause of what you are seeing. >=20 > I've about used up my investigation time for right now, but what I've > found is that onetime providers wind up with no md_magic and no (0) > md_version, so eli_metadata_decode() EINVAL's right up at the top > before filling anything into the passed md. As a result, in > g_eli_ctl_configure(), it gets (keeps) stack garbage in the var. If g_eli_configure() is changed to not (try to) read and write metadata for onetime providers it seems to work as expected: https://www.fabiankeil.de/sourcecode/electrobsd/g_eli_ctl_configure-Do-not-= try-to-read-or-write-meta-from-onetime-providers.diff A nicer looking solution would be moving all the metadata fiddling below a if (sc->sc_flags & G_ELI_FLAG_ONETIME) block at the end of the function where md.md_flags could inherit the flags from sc->sc_flags. Fabian --Sig_/duOBSR7HPL.IQWZK4+m/pIr Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUG5hQACgkQBYqIVf93VJ0GGwCgtp+uExejVVOL42oQ068ic33F HD8Ani8TkhnAc8gSSy4A8gqBIs6a+9db =Eyev -----END PGP SIGNATURE----- --Sig_/duOBSR7HPL.IQWZK4+m/pIr-- From owner-freebsd-geom@FreeBSD.ORG Tue Mar 17 01:43:42 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 DCDB87F4; Tue, 17 Mar 2015 01:43:42 +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 B0772895; Tue, 17 Mar 2015 01:43: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 CC38137B403; Mon, 16 Mar 2015 20:43:34 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3l5cj21bS8zws; Mon, 16 Mar 2015 20:43:34 -0500 (CDT) Date: Mon, 16 Mar 2015 20:43:34 -0500 From: "Matthew D. Fuller" To: Pawel Jakub Dawidek Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150317014334.GH52331@over-yonder.net> 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> <20150316100030.GB1515@garage.freebsd.pl> <20150316101323.GD52331@over-yonder.net> <20150316101843.GE52331@over-yonder.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150316101843.GE52331@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 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: Tue, 17 Mar 2015 01:43:43 -0000 > [...] because in g_eli_read_metadata(), it doesn't check the return > from eli_metadata_decode(), so it doesn't notice the EINVAL and > happily reports back success without ever having touched the md :( Fixing that is enough to prevent the panic at any rate. At least in the normal case; if it randomly gets good magic, weird stuff might still happen. But that lack of checking is a Real Bug by itself anyway, so merits a fix. Index: g_eli.c =================================================================== --- g_eli.c (revision 280158) +++ g_eli.c (working copy) @@ -633,7 +633,9 @@ g_topology_lock(); if (buf == NULL) goto end; - eli_metadata_decode(buf, md); + error = eli_metadata_decode(buf, md); + if (error != 0) + goto end; end: if (buf != NULL) g_free(buf); (yes, the goto is redundant as all heck there. I decided to put it in for symmetry with the other checking, as well as for a JIC, if e.g. some code later got inserted after the decode before the end: label) So for the moment, I've reinstated the conditional in geli-delete.5.patch (which includes the above, though it's worthy of commission by itself anyway). Technically it shouldn't be necessary with that, since it'll fail on the reading anyway, but geli: Cannot change configuration of onetime provider ada0s1.nop. is friendlier and more informative than geli: Cannot read metadata from ada0s1.nop (error=22). and it also provides a convenient point to leave a comment about why it doesn't [yet] work, until it does. -- 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 Tue Mar 17 02:20: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 020C6C31 for ; Tue, 17 Mar 2015 02:20:37 +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 C9DA1B95 for ; Tue, 17 Mar 2015 02:20:36 +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 76AC437B4A0; Mon, 16 Mar 2015 21:20:35 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3l5dWj6hyczxD; Mon, 16 Mar 2015 21:20:33 -0500 (CDT) Date: Mon, 16 Mar 2015 21:20:33 -0500 From: "Matthew D. Fuller" To: Fabian Keil Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150317022033.GI52331@over-yonder.net> 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> <20150316100030.GB1515@garage.freebsd.pl> <20150316101323.GD52331@over-yonder.net> <3d5629f4.63dcb347@fabiankeil.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3d5629f4.63dcb347@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 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: Tue, 17 Mar 2015 02:20:37 -0000 On Mon, Mar 16, 2015 at 03:17:58PM +0100 I heard the voice of Fabian Keil, and lo! it spake thus: > > If g_eli_configure() is changed to not (try to) read and write > metadata for onetime providers it seems to work as expected: At a glance, that looks reasonable to me (with the usual caveat about how I'm really only pretending that I know what I'm doing here ;). It does mean we're twiddling some bits in memory we never initialized and never read from after (md.md_foo) in the ONETIME case, but that doesn't seem like it'd be harmful. It's just a few wasted instructions in a rare, manually-triggered codepath; not IMO worth the loss in readability of sprinkling more conditionals through it. > A nicer looking solution would be moving all the metadata fiddling > below a if (sc->sc_flags & G_ELI_FLAG_ONETIME) block at the end of > the function where md.md_flags could inherit the flags from > sc->sc_flags. I wonder. Is it actually safe to assume they should always wind up the same? I'd think the sc at least potentially has things set the md doesn't. For instance, if you 'geli attach -r' something, it's read-only THIS time, so the sc has _FLAG_RO set, but not necessary in general, so the on-disk metadata might not? I don't actually know if that's the case, but it sounds like a reasonable thing to do, and it certainly sounds like a reasonable _class_ of things to do, so I'd be hesitant about thinking that flags = sc->flags; mess_with(flags); sc->flags = md->flags = flags; would be a thing we'd want to do. I s'pose you could do it instead with a pair of set_flags/unset_flags vars built with just the changes, that are |='d/&='d down at the bottom, but that just sounds like it'd make things even less readable. Maybe if we had 15 or 20 bits we might be flipping, but we've got 2. -- 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 19 13:03:08 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 1778D711 for ; Thu, 19 Mar 2015 13:03:08 +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 F1E7DDD4 for ; Thu, 19 Mar 2015 13:03:07 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2JD37Kc019559 for ; Thu, 19 Mar 2015 13:03:07 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bug 197309] ggatec has been broken since rev 238119 Date: Thu, 19 Mar 2015 13:03:07 +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.0-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: fk@fabiankeil.de 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: 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, 19 Mar 2015 13:03:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197309 --- Comment #3 from fk@fabiankeil.de --- The steps work as expected for me. Tested on: FreeBSD kendra 10.1-STABLE FreeBSD 10.1-STABLE #0 r279989+96d5981(stable/10): Tue Mar 17 19:45:41 CET 2015 fk@kendra:/usr/obj/usr/src/sys/GENERIC amd64 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-geom@FreeBSD.ORG Thu Mar 19 16:47:46 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 F323C836 for ; Thu, 19 Mar 2015 16:47:45 +0000 (UTC) Received: from sb5y.unisonplatform.com (sb5y.unisonplatform.com [69.194.230.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE3B6D3A for ; Thu, 19 Mar 2015 16:47:45 +0000 (UTC) Received: from jdpplast by sb5y.unisonplatform.com with local (Exim 4.84) (envelope-from ) id 1YYdbi-003Y76-EM for freebsd-geom@freebsd.org; Thu, 19 Mar 2015 11:47:42 -0500 To: freebsd-geom@freebsd.org Subject: FREE, Shipment delivery problem #00757174 Date: Thu, 19 Mar 2015 11:47:41 -0500 From: "FedEx International Ground" Reply-To: "FedEx International Ground" Message-ID: <2ddb8b349f57e15e05191b4c40906005@sb5y.unisonplatform.com> X-Priority: 3 MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sb5y.unisonplatform.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [606 605] / [47 12] X-AntiAbuse: Sender Address Domain - sb5y.unisonplatform.com Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 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, 19 Mar 2015 16:47:46 -0000 Dear Free, Your parcel has arrived at March 18. Courier was unable to deliver the parcel to you. Please, open email attachment to print shipment label. Sincerely, Chester Post, FedEx Operation Agent. From owner-freebsd-geom@FreeBSD.ORG Fri Mar 20 03:08:39 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 B99FE44F for ; Fri, 20 Mar 2015 03:08:39 +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 9F20E36B for ; Fri, 20 Mar 2015 03:08:39 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2K38d8w094329 for ; Fri, 20 Mar 2015 03:08:39 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: Fri, 20 Mar 2015 03:08:39 +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: allanjude@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: 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: Fri, 20 Mar 2015 03:08:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183401 Allan Jude changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |allanjude@FreeBSD.org --- Comment #2 from Allan Jude --- I've seen a similar issue with ZFS zvol's, which was solved by adding a 'dev' mode that doesn't get picked up by GEOM. Might be worth looking at how it is done in the freebsd bits for ZFS. the sysctl is: vfs.zfs.vol.mode and the ZFS property is volmode -- You are receiving this mail because: You are on the CC list for the bug.