From owner-freebsd-geom@FreeBSD.ORG Sun Mar 8 00:09:44 2015 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED2EFBF4; Sun, 8 Mar 2015 00:09:44 +0000 (UTC) Received: from thyme.infocus-llc.com (thyme.infocus-llc.com [199.15.120.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AB004929; Sun, 8 Mar 2015 00:09:43 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 0218237B55B; Sat, 7 Mar 2015 18:01:32 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3l02sR1WzVz22S; Sat, 7 Mar 2015 18:01:31 -0600 (CST) Date: Sat, 7 Mar 2015 18:01:31 -0600 From: "Matthew D. Fuller" To: freebsd-geom@freebsd.org Subject: RFC: Pass TRIM through GELI Message-ID: <20150308000131.GP1742@over-yonder.net> MIME-Version: 1.0 X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.23-fullermd.4 (2014-03-12) X-Virus-Scanned: clamav-milter 0.98.6 at thyme.infocus-llc.com X-Virus-Status: Clean Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: pjd@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 00:09:45 -0000 [ bcc'd to -fs because it's been discussed there in the past; followup to -geom because that seems where it belongs ] I've done a quick implementation of TRIM passthru support for GELI. Patch attached is against late Feb -CURRENT; however, a glance at svn suggests this code hasn't changed much, so it's probably pretty portable forward and back. It applies cleanly to a stable/10 tree though I haven't tried compiling or using it there. This has been lightly tested and seems to work fine. It adds a '-t' flag to init and onetime to enable passthru on the new provider, and '-t/-T' options to configure to en/disable on existing (but see caveat below about metadata versions; as written, you can't use this on existing partitions). Since all we're doing is passing it through instead of denying it, I'd expect "seems to work" to be pretty much the same as "does work"; the requests go through, space clears up, and messing with a little ZFS on top of it doesn't show up any data corruption. The patch to gnop in is a useful adjunct in checking when/if the requests actually go through, by making the .eli on top of the .nop and seeing when the counters tick. In this implementation, I added a new G_ELI_VERSION and required it for setting the flag. I actually think this is probably not necessary; all we do is set a value in the flags field, and if it's loaded onto a system that doesn't know what to do with that value, it'll just do nothing, which IMO is fine. And since there is no `geli upgrade`, this means that you can't enable it on any existing partitions, but have to kill/init from scratch, which isn't very user-friendly. So I propose that it actually be done sans those version changes, but they are in the patch as attached for now. One not-quite-related change in here is that I added a denial for 'geli configure' attempts on onetime providers. Trying this causes a panic, as the metadata version field on onetime providers is nonsensical. As far as I can tell in quick testing, this isn't related to my changes; it happens with stock GELI code as well. Presumably it's never been noticed before since the only prior use for 'geli configure' was to un/set the BOOT flag, which makes no sense on a onetime anyway, so nobody ever bothered trying. But with -[tT], somebody might try. Evidence: I did, and found the panic :) -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.