From owner-freebsd-geom@FreeBSD.ORG Sun Mar 8 13:29:14 2015 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0415FD3 for ; Sun, 8 Mar 2015 13:29:13 +0000 (UTC) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 76772E13 for ; Sun, 8 Mar 2015 13:29:12 +0000 (UTC) Received: by widfb4 with SMTP id fb4so3368270wid.0 for ; Sun, 08 Mar 2015 06:29:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UbOCfEIB6v8f3Ozxnws2udab9yPg9tNfva8p3IVCbaE=; b=UdzN2cksvQlvOJpRh/KGDfEaty2yxpkjmteS+nEUL4PS0ZrJf8j3TGEn3F6oDJplot ZMR70jmG126bWTVBsopcokR1ctjNs+6+eWFvZ4dutY1cxjFabXYhslIEXJjBke320qNw Gtks2Dy40JcZtn+abL2oCkq0S+rSYndxzwnZsRda4ofFBLRCx0j+7L1vi4ib4gWZMDdA GxRmNEfw5ew2fFDVHSqdJXsOyeb8ttZMYzXBqZRV6bkJIFeEN+tODjizEPWDL53uxIUx 79+c0+GRX4sBFjrQD18mS/az/fCAfNkuqR+g49uh4GSFItIlg4pJD6oKqVXhoin/tiqX XewA== X-Gm-Message-State: ALoCoQlcyIt5d1nKnu5ptZ/U9oixvwUuDdreldMaIfFkOe47YXWF3Y2ccP2ZA618uBI3yz7oyMmb X-Received: by 10.180.109.70 with SMTP id hq6mr11762611wib.16.1425821345212; Sun, 08 Mar 2015 06:29:05 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id cf12sm23809014wjb.10.2015.03.08.06.29.03 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Mar 2015 06:29:04 -0700 (PDT) Message-ID: <54FC4E99.4080202@multiplay.co.uk> Date: Sun, 08 Mar 2015 13:28:57 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-geom@freebsd.org Subject: Re: RFC: Pass TRIM through GELI References: <20150308000131.GP1742@over-yonder.net> In-Reply-To: <20150308000131.GP1742@over-yonder.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 13:29:14 -0000 I don't see where your checking if the underlying device supports DELETE? On 08/03/2015 00:01, Matthew D. Fuller wrote: > [ bcc'd to -fs because it's been discussed there in the past; followup > to -geom because that seems where it belongs ] > > I've done a quick implementation of TRIM passthru support for GELI. > Patch attached is against late Feb -CURRENT; however, a glance at svn > suggests this code hasn't changed much, so it's probably pretty > portable forward and back. It applies cleanly to a stable/10 tree > though I haven't tried compiling or using it there. > > This has been lightly tested and seems to work fine. It adds a '-t' > flag to init and onetime to enable passthru on the new provider, and > '-t/-T' options to configure to en/disable on existing (but see caveat > below about metadata versions; as written, you can't use this on > existing partitions). > > Since all we're doing is passing it through instead of denying it, I'd > expect "seems to work" to be pretty much the same as "does work"; the > requests go through, space clears up, and messing with a little ZFS on > top of it doesn't show up any data corruption. > > The patch to gnop in > is a useful > adjunct in checking when/if the requests actually go through, by > making the .eli on top of the .nop and seeing when the counters tick. > > > In this implementation, I added a new G_ELI_VERSION and required it > for setting the flag. I actually think this is probably not > necessary; all we do is set a value in the flags field, and if it's > loaded onto a system that doesn't know what to do with that value, > it'll just do nothing, which IMO is fine. And since there is no `geli > upgrade`, this means that you can't enable it on any existing > partitions, but have to kill/init from scratch, which isn't very > user-friendly. So I propose that it actually be done sans those > version changes, but they are in the patch as attached for now. > > > One not-quite-related change in here is that I added a denial for > 'geli configure' attempts on onetime providers. Trying this causes a > panic, as the metadata version field on onetime providers is > nonsensical. As far as I can tell in quick testing, this isn't > related to my changes; it happens with stock GELI code as well. > Presumably it's never been noticed before since the only prior use for > 'geli configure' was to un/set the BOOT flag, which makes no sense on > a onetime anyway, so nobody ever bothered trying. But with -[tT], > somebody might try. Evidence: I did, and found the panic :) > >