From owner-freebsd-geom@FreeBSD.ORG Tue Jul 22 19:57:16 2008 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A92891065673 for ; Tue, 22 Jul 2008 19:57:16 +0000 (UTC) (envelope-from xd888cc7541309c3f@f4n.org) Received: from lore.f4n.org (2-1-6-25b.va.gbg.bostream.se [82.182.120.239]) by mx1.freebsd.org (Postfix) with SMTP id DC5748FC2B for ; Tue, 22 Jul 2008 19:57:15 +0000 (UTC) (envelope-from xd888cc7541309c3f@f4n.org) Received: (qmail 6308 invoked by uid 1000); 22 Jul 2008 19:31:37 -0000 Date: Tue, 22 Jul 2008 21:31:37 +0200 From: Pete To: freebsd-geom@freebsd.org Message-ID: <20080722193136.GA12642@lore.f4n.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Moving GELI to an oversized provider X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 19:57:16 -0000 Due to an operator error (posted to freebsd-questions a week ago, "Using RocketRAID 1810A (hptmv) as an ordinary controller?") I have ended up with a bunch of disks having GELI inside a GEOM labeled provider, but everything offset 10 sectors from the end of the disk. That is, GEOM::ELI metadata is 11 sectors from the end of the disk and GEOM::LABEL is 10 sectors from the end. The content of the last ten sectors is unimportant and can be overwritten. In order to avoid having to rewrite all data I readded a GEOM label, placing it at the very last sector (but leaving the old one in place). I then 'geli restore':ed the GELI metadata to the newly created label, so that the end of the disk looks like: sector -1: new GEOM label sector -2: copy of old GELI metadata ... sector -10: old GEOM label sector -11: old GELI metadata This appears to be working just fine but I worry about gotchas, for instance if GELI were to access data by negative offset from the end of the provider (or would this be highly unnatural, making it unlikely even in future versions?). I notice that g_eli_taste in g_eli.c compares the stored size with the provider's size, but perhaps this is only an issue for the root file system (making it irrelevant for me)? Finally, is there a "clean" solution to this, for instance setting up an in-memory GEOM provider which references a certain slice of a disk? (Based on the documentation it appears as if NetBSD's "dkctl addwedge" does this, perhaps there is a FreeBSD equivalent.) Any comments would be appreciated!