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."