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.