Date: Tue, 22 Jul 2008 21:31:37 +0200 From: Pete <xd888cc7541309c3f@f4n.org> To: freebsd-geom@freebsd.org Subject: Moving GELI to an oversized provider Message-ID: <20080722193136.GA12642@lore.f4n.org>
next in thread | raw e-mail | index | archive | help
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!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080722193136.GA12642>