From owner-freebsd-geom@freebsd.org Sun Jul 12 21:00:10 2015 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4ECCA99B113 for ; Sun, 12 Jul 2015 21:00:10 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) 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 28BC515A4 for ; Sun, 12 Jul 2015 21:00:10 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t6CL09nP049421 for ; Sun, 12 Jul 2015 21:00:09 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201507122100.t6CL09nP049421@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-geom@FreeBSD.org Subject: Problem reports for freebsd-geom@FreeBSD.org that need special attention X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 Date: Sun, 12 Jul 2015 21:00:09 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2015 21:00:10 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 197309 | ggatec broken since r238119 (ioctl(/dev/ggctl): I Open | 197309 | ggatec broken since r238119 (ioctl(/dev/ggctl): I 2 problems total for which you should take action. From owner-freebsd-geom@freebsd.org Mon Jul 13 09:57:49 2015 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 025D49981B8 for ; Mon, 13 Jul 2015 09:57:49 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (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 956571F35 for ; Mon, 13 Jul 2015 09:57:48 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by wgxm20 with SMTP id m20so108566636wgx.3 for ; Mon, 13 Jul 2015 02:57:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=pi9u6X+kBY1tQQxOtumcDI4rX2/5YdTnNHOLlC4Rmyc=; b=PagIqSqy0bzor91sih50fA8lKgIfd3t42mg5sEHBA2JVuFN0D2RrPKO+5e5VCGdGnc bsoHygmrUnTxmFArqjmp6KfHi7mR23S2/tjXvAMQD4pnD+iuIWGN/nwqkv8yCVSFXqo9 ZKJn6eya28xZ5gl+ovu5C9YUgH313Wf6CYI5synQNQx0Dlc4OyS1lOMgMWUGyUoSzwhP PFZ5MsIWooktlher+cfsDWWEoaJa+oFV94s6MdfBD11bI1c6m35N0sC75Za6Bp2paRzS VbTLnChYBDvPtlKo4C2zLgMSE/ub3zzVjtEtkj9DGoShagP8Mjs0SEm4NpMuSyjj03ZL AkvA== X-Gm-Message-State: ALoCoQkgWPF4uXarwdf7RsSLFLIc2STCDDaYGas/y6889Aiebf0W+jM5qFuuWuESc6WAFQ4dqzR/ X-Received: by 10.194.157.165 with SMTP id wn5mr3811336wjb.69.1436781461284; Mon, 13 Jul 2015 02:57:41 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by smtp.gmail.com with ESMTPSA id gt10sm13621290wib.20.2015.07.13.02.57.40 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Jul 2015 02:57:40 -0700 (PDT) Subject: Re: RFC: Pass TRIM through GELI To: freebsd-geom@freebsd.org References: <20150308000131.GP1742@over-yonder.net> <20150324021924.GQ52331@over-yonder.net> <20150502125220.GS78376@over-yonder.net> <20150629013841.GO50491@over-yonder.net> <20150710200055.GB1270@garage.freebsd.pl> From: Steven Hartland Message-ID: <55A38B92.5010902@multiplay.co.uk> Date: Mon, 13 Jul 2015 10:57:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150710200055.GB1270@garage.freebsd.pl> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 09:57:49 -0000 On 10/07/2015 21:01, Pawel Jakub Dawidek wrote: > On Sun, Jun 28, 2015 at 08:38:41PM -0500, Matthew D. Fuller wrote: >>>> Stuffed into bugzilla as >>>> >>> [...] >>>> After last round, everybody seems happy enough with this, so I've >>>> filed it as >>>> . >>> Does anybody have outstanding concerns on these? Or, if not, what >>> else do we need to move them along? They're working fine for me >>> here... >> Ping... still working fine here, and I'm pretty sure I've addressed >> every concern anybody's raised. > Matthew, > > I'm sorry that it took me so long to get to your patch. > > The good news is that I like the patch - it looks clean and complete. > The bad news is that I like it a bit too much:) I think I'd prefer that > BIO_DELETE is passed through by default and there is an option to turn > it off. This would mean changing -t option to -T for init and onetime > and renaming the G_ELI_FLAG_DELETE flag to G_ELI_FLAG_IGNORE_DELETE. > OR... just removing the ability to ignore BIO_DELETEs. The latter is > appealing especially if some days we will implement BIO_DELETEs as > overwrites. Then we should have an option to turn that on, which would > turn off TRIM/UNMAP. > > Thinking about it some more, I believe that if someone doesn't want > TRIM/UNMAP to hit his SSDs it should be configurable on per-SSD basis > and not on every layer above SSD. So at the end I'd change my preference > to just passing BIO_DELETEs always. This can already be achieved for devices attached via cam/scsi_da e.g. kern.cam.da.1.delete_method="NONE" > > What do you think? > From owner-freebsd-geom@freebsd.org Mon Jul 13 15:30:25 2015 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9262799B47F for ; Mon, 13 Jul 2015 15:30:25 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 5C19AF8A for ; Mon, 13 Jul 2015 15:30:24 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id 3383A573; Mon, 13 Jul 2015 17:30:18 +0200 (CEST) Date: Mon, 13 Jul 2015 17:31:46 +0200 From: Pawel Jakub Dawidek To: RW Cc: freebsd-geom@freebsd.org Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150713153146.GA1984@garage.freebsd.pl> References: <20150308000131.GP1742@over-yonder.net> <20150324021924.GQ52331@over-yonder.net> <20150502125220.GS78376@over-yonder.net> <20150629013841.GO50491@over-yonder.net> <20150710200055.GB1270@garage.freebsd.pl> <20150710222837.GE96394@over-yonder.net> <20150711141553.3fcf91f4@gumby.homeunix.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline In-Reply-To: <20150711141553.3fcf91f4@gumby.homeunix.com> X-OS: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 15:30:25 -0000 --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 11, 2015 at 02:15:53PM +0100, RW via freebsd-geom wrote: > On Fri, 10 Jul 2015 17:28:37 -0500 > Matthew D. Fuller wrote: >=20 >=20 > > 2) Security. For whatever your threat model is, leaking the "how much > > space is in use" datum is unacceptable.=20 >=20 > It's not about how much space is free, it's about giving away which > blocks do and don't contain data. >=20 > Perhaps more importantly TRIM breaks plausible deniabily, which was > the the point of allowing the geli metadata to be store separately. You > can't argue that a partition has been wiped with 'dd if=3D/dev/random ...' > if the the partition has been subsequently trimmed. Yes, you are right. I even suggest in man page to overwrite providers with random data before using them. So what do you guys think about implementing trim support this way: geli -d 'overwrite' may be implemented later and 'trim' would be the default? This option bascially defines how BIO_DELETE should be handled. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --17pEHd4RhPHOinZp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVo9niAAoJEJVLhSuxKFt1vRoQAJMVEsKgE8n4C6sGmEXI0sSe 3A73GwHIXzVAnaMP2I99QrJ8imwOdsJbG+T0DD88VZ+O4mt0k7tnSgdAhyFCMN9i uIjPQwAzGhzBgwQersIEg0GsY6VHr6IkrpzP88YPDah+M9h5kx/cuDRvLYXFNC91 a1zL7EbOw5XaggCIFC2Br9p3m2nTlf+PHa2yjFASM6WQa3grtBFsov/8fWnCjk3J z33UvHNLQPJRYB9+f65SW2zGtP8302LDu4z23hU+11UrS0wr/fSEMDLwJAghqcW5 1e8kW0srwaCCFHe0ILkJNCM/+jSX3caKIhFMk3JJXv6owxdi+KjObRQkxEE4sWCP RaFIc5XFoRXqKIsFJ0kaHqe7FxKI/pg7vjkpExADI0f1XV5qHpcOphsTUzxIVwM4 WVBFGbojP6Yk2Q/i9ZAOQailR86hty+kJsyBzPw9eWv6YsL5U4VZp/iQSvSPa7CV SU316AXp8+pDPn1bchG+wuA4jIgyuo5HXLWgHh3fqxuTXMSNPqC6d023RLWFT65l ZMGRPN9ugq4io/O9/O9GcvJh/C38riBwD5JUr+PkySRKTQettXYFSb475YROc5ID Mqg88wosa/+6lnc5cI2EcQDiG2GGynCTLwDTyGOnkHchO7oM1rSjdh6OkJRNMjCi ERAHBbjz5zMX0Gd+dZaw =1fSN -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp-- From owner-freebsd-geom@freebsd.org Tue Jul 14 03:13:51 2015 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3EC9991A5 for ; Tue, 14 Jul 2015 03:13:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 2B1E31F09 for ; Tue, 14 Jul 2015 03:13:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t6E3Dphr035255 for ; Tue, 14 Jul 2015 03:13:51 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bug 201504] [geom_part] gpart bootcode highly ambiguous message (the wrong size) Date: Tue, 14 Jul 2015 03:13:51 +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: 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.20 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 03:13:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201504 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 Tue Jul 14 06:42:21 2015 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 488C299C522 for ; Tue, 14 Jul 2015 06:42:21 +0000 (UTC) (envelope-from fullermd@over-yonder.net) 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 20D991C0; Tue, 14 Jul 2015 06:42:20 +0000 (UTC) (envelope-from fullermd@over-yonder.net) 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 C61E737B4A0; Tue, 14 Jul 2015 01:42:12 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3mVshh0p87z1bX; Tue, 14 Jul 2015 01:42:12 -0500 (CDT) Date: Tue, 14 Jul 2015 01:42:12 -0500 From: "Matthew D. Fuller" To: Pawel Jakub Dawidek Cc: RW , freebsd-geom@freebsd.org Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150714064212.GZ96394@over-yonder.net> References: <20150308000131.GP1742@over-yonder.net> <20150324021924.GQ52331@over-yonder.net> <20150502125220.GS78376@over-yonder.net> <20150629013841.GO50491@over-yonder.net> <20150710200055.GB1270@garage.freebsd.pl> <20150710222837.GE96394@over-yonder.net> <20150711141553.3fcf91f4@gumby.homeunix.com> <20150713153146.GA1984@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150713153146.GA1984@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.7 at thyme.infocus-llc.com X-Virus-Status: Clean X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 06:42:21 -0000 On Mon, Jul 13, 2015 at 05:31:46PM +0200 I heard the voice of Pawel Jakub Dawidek, and lo! it spake thus: > > So what do you guys think about implementing trim support this way: > > geli -d > > 'overwrite' may be implemented later and 'trim' would be the default? Well, if you ask me, we can work out the UI for a 3-way choice when a third way is implemented. Doing shredding would presumably be noted by adding another flag[0] for it anyway, so doing it on top of this patch oughtn't take it out of its way. Nobody's implemented it in the last 10 years that there's been a comment suggesting it. So, from my selfish perspective, I'd as soon land this as a solid step forward, and worry about a shredding implementation when one gets written... [0] I mean, I _guess_ we could add another element into the metadata/softc structs just to hold a 3-way 'delete handling' option, but that sounds way heavier-weight than necessary. Also would need new geli version and blah. -- 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 Jul 14 10:08:11 2015 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF55C99BC66 for ; Tue, 14 Jul 2015 10:08:11 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 96D42B4 for ; Tue, 14 Jul 2015 10:08:11 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id D0546796; Tue, 14 Jul 2015 12:08:08 +0200 (CEST) Date: Tue, 14 Jul 2015 12:09:38 +0200 From: Pawel Jakub Dawidek To: "Matthew D. Fuller" Cc: RW , freebsd-geom@freebsd.org Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150714100936.GA1239@garage.freebsd.pl> References: <20150308000131.GP1742@over-yonder.net> <20150324021924.GQ52331@over-yonder.net> <20150502125220.GS78376@over-yonder.net> <20150629013841.GO50491@over-yonder.net> <20150710200055.GB1270@garage.freebsd.pl> <20150710222837.GE96394@over-yonder.net> <20150711141553.3fcf91f4@gumby.homeunix.com> <20150713153146.GA1984@garage.freebsd.pl> <20150714064212.GZ96394@over-yonder.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: <20150714064212.GZ96394@over-yonder.net> X-OS: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 10:08:12 -0000 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 14, 2015 at 01:42:12AM -0500, Matthew D. Fuller wrote: > On Mon, Jul 13, 2015 at 05:31:46PM +0200 I heard the voice of > Pawel Jakub Dawidek, and lo! it spake thus: > >=20 > > So what do you guys think about implementing trim support this way: > >=20 > > geli -d > >=20 > > 'overwrite' may be implemented later and 'trim' would be the default? >=20 > Well, if you ask me, we can work out the UI for a 3-way choice when a > third way is implemented. Doing shredding would presumably be noted > by adding another flag[0] for it anyway, so doing it on top of this > patch oughtn't take it out of its way. Nobody's implemented it in the > last 10 years that there's been a comment suggesting it. >=20 > So, from my selfish perspective, I'd as soon land this as a solid step > forward, and worry about a shredding implementation when one gets > written... >=20 >=20 > [0] I mean, I _guess_ we could add another element into the > metadata/softc structs just to hold a 3-way 'delete handling' > option, but that sounds way heavier-weight than necessary. Also > would need new geli version and blah. I wanted to avoid changing command line arguments in the future for people who automate GELI creation, but you know what, I just realized that TRIM/UNMAP and overwrite are not mutually exclusive. I may want to overwrite first and then do the TRIM. If those two are not mutually exclusive then, finally, I think your patch is fine! Thank you for your patience and expect the commit soon:) --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVpN/gAAoJEJVLhSuxKFt1pMgP/jkyhKxgglwGbW7YdoZ8rq9K RKqqME/v/HMbQr2PIJula2e4gdNsXvPAqUI65B7VS09rDhY+1k1aDD2Kz3DAuEaC 2gQ5o/OH0R02z4Gki0iZr6Gq9Dtpn0q3g4VDLsX507F45Erbpw9pss654ye5uxhi 0aXaZFMWaeC9gl9FjqHFnXHb8zOE03EX4C6S4XOFcrfI9CoJTO9nFvzZjwNoEiYx pQHA6Iv4wYCSsOVKD7QWrHGetOs8pFaKiR9T/x+peB2IKdjmpKfa9jt5Iz8tM8Ho SdkVSRxs0jqF5+TfrBloeJOlK2BCMP3tYPSNrqahZGvJw8VMCQ/XPzuHUYKlXQGt +QoCXLKXwOZwjlnDOvJr23jFRBLIuUQrQ2g6FkTDKGUBh2DtfFbfttEGJJ7uuRdk o2fhGyPd0qz1Mo7FiSMJrSSupg6Dvtk9Z5kcQs1nhcQf5q9Fjl3vRW3KLGTHfWN7 8x6iaC/6eQy4X9Zn/QkjprtG9DkqTCFtfHVzq3RAeGfnJFyco5RRRI1zQuMdqJj/ QR7ajk/r42szvYFT74uOxCPWCENOs3jm5yTsUxOgewdhmYlJuYLZyiEMoXPtIenI +0AFWxyQqPQFz0/OsEop+gkFQG+VjXKycf8Zi1B6wHgIKh5DNFP+baS/YWSDEsFL sT7BW1R6hpIa92XlZScM =pZJq -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR-- From owner-freebsd-geom@freebsd.org Tue Jul 14 10:49:53 2015 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5E9699C811 for ; Tue, 14 Jul 2015 10:49:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 C15C6BE6 for ; Tue, 14 Jul 2015 10:49:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t6EAnr3P063033 for ; Tue, 14 Jul 2015 10:49:53 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bug 197309] ggatec broken since r238119 (ioctl(/dev/ggctl): Invalid argument) Date: Tue, 14 Jul 2015 10:49:52 +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-STABLE X-Bugzilla-Keywords: easy, needs-qa, patch, patch-ready, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-geom@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: mfc-stable10? 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.20 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 10:49:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197309 --- Comment #9 from commit-hook@freebsd.org --- A commit references this bug: Author: brueffer Date: Tue Jul 14 10:49:37 UTC 2015 New revision: 285531 URL: https://svnweb.freebsd.org/changeset/base/285531 Log: Unbreak ggatec and ggatel on i386 after r238119, which added two more 'struct g_gate_ctl_create' fields. While the behaviour was technically undefined on other architectures as well, on the reporter's amd64 systems the uninitialized bytes the kernel cares about were always zero so everything worked as expected. PR: 197309, 199559 Submitted by: ota@j.email.ne.jp, Fabian Keil Reviewed by: pjd MFC after: 1 week Changes: head/sbin/ggate/ggatec/ggatec.c head/sbin/ggate/ggatel/ggatel.c -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-geom@freebsd.org Tue Jul 14 10:51:39 2015 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E25BA99C9A4 for ; Tue, 14 Jul 2015 10:51:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 CD63AFCE for ; Tue, 14 Jul 2015 10:51:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t6EApdG6068797 for ; Tue, 14 Jul 2015 10:51:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bug 197309] ggatec broken since r238119 (ioctl(/dev/ggctl): Invalid argument) Date: Tue, 14 Jul 2015 10:51:40 +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-STABLE X-Bugzilla-Keywords: easy, needs-qa, patch, patch-ready, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: brueffer@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: brueffer@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: mfc-stable10? X-Bugzilla-Changed-Fields: assigned_to bug_status 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.20 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 10:51:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197309 Christian Brueffer changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-geom@FreeBSD.org |brueffer@FreeBSD.org Status|Open |In Progress CC| |brueffer@FreeBSD.org --- Comment #10 from Christian Brueffer --- Fixed in HEAD, I'll MFC this in a week. Thanks! -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-geom@freebsd.org Wed Jul 15 02:17:17 2015 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BEE209A253A for ; Wed, 15 Jul 2015 02:17:17 +0000 (UTC) (envelope-from fullermd@over-yonder.net) 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 99E13196A; Wed, 15 Jul 2015 02:17:17 +0000 (UTC) (envelope-from fullermd@over-yonder.net) 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 7B7D937B402; Tue, 14 Jul 2015 21:17:15 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3mWMmV55rzz29D; Tue, 14 Jul 2015 21:17:14 -0500 (CDT) Date: Tue, 14 Jul 2015 21:17:14 -0500 From: "Matthew D. Fuller" To: kpneal@pobox.com Cc: Pawel Jakub Dawidek , RW , freebsd-geom@freebsd.org Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150715021714.GL96394@over-yonder.net> References: <20150324021924.GQ52331@over-yonder.net> <20150502125220.GS78376@over-yonder.net> <20150629013841.GO50491@over-yonder.net> <20150710200055.GB1270@garage.freebsd.pl> <20150710222837.GE96394@over-yonder.net> <20150711141553.3fcf91f4@gumby.homeunix.com> <20150713153146.GA1984@garage.freebsd.pl> <20150714064212.GZ96394@over-yonder.net> <20150714100936.GA1239@garage.freebsd.pl> <20150714214813.GA65182@neutralgood.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150714214813.GA65182@neutralgood.org> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.23-fullermd.4 (2014-03-12) X-Virus-Scanned: clamav-milter 0.98.7 at thyme.infocus-llc.com X-Virus-Status: Clean X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 02:17:17 -0000 On Tue, Jul 14, 2015 at 05:48:13PM -0400 I heard the voice of kpneal@pobox.com, and lo! it spake thus: > > Who says that a write to a logical block in an SSD will result in a > write to the same physical block? I thought it would typically or at > least frequently go to a different physical block. Wear levelling > and all that. Yes, it wouldn't be useful on a SSD (or a zvol, or any other backing that acts in a COW-ish way). And it's meaningless combining TRIM and shredding on a traditional platter drive, since it wouldn't do the TRIM part. Still, there can be some situations that would be both directly overwriting, and supporting unused-space-notifications; some virtualized SAN setups for instance, or or a md/VM/etc block device that supported sparse usage. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.