From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 8 16:19:48 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7027F16A4CE for ; Sat, 8 Nov 2003 16:19:48 -0800 (PST) Received: from mailbox.univie.ac.at (mail.univie.ac.at [131.130.1.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1B6743FE9 for ; Sat, 8 Nov 2003 16:19:46 -0800 (PST) (envelope-from l.ertl@univie.ac.at) Received: from [10.0.0.2] (adslle.cc.univie.ac.at [131.130.102.11]) by mailbox.univie.ac.at (8.12.10/8.12.10) with ESMTP id hA90Jbjc423276 for ; Sun, 9 Nov 2003 01:19:39 +0100 Date: Sun, 9 Nov 2003 01:19:33 +0100 (CET) From: Lukas Ertl To: hackers@freebsd.org Message-ID: <20031109003617.K626@korben.in.tern> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-DCC-ZID-Univie-Metrics: mx1 4242; Body=0 Fuz1=0 Fuz2=0 Subject: geom_mirror implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2003 00:19:48 -0000 Hi hackers@, I've played around with GEOM a bit and beefed up geom_mirror, which is already in the tree but not built yet. You can find the patch at . The patch does the following: *) modify geom_mirror.c and add a sync, a config, a dumpconf and a destroy routine. It also implements on-disk meta data to determine if a mirror is in sync or not. *) create the directory and Makefile needed for building a geom_mirror KLD. *) create a rudimentary gmirror tool that can be used to configure the mirror (a manpage for it is still to come). Everything is far from being complete, and there are still some rough edges, but basically the mirror works, although you should consider it experimental, of course. How to use it: *) Create a mirror from two slices: # gmirror -c create -l mylabel /dev/ad0s2 /dev/ad2s2 *) Likewise, create a mirror from two partitions: # gmirror -c create -l mylabel /dev/ad0s2a /dev/ad2s2a *) Create a (half-complete) mirror with one disk, add a second disk, and sync them: # gmirror -c create -l mylabel /dev/ad0s2 # gmirror -c add -l mylabel /dev/ad2s2 # gmirror -c sync -l mylabel *) Destroy the on-disk meta data that identifies a device as part of a mirror: # gmirror -c remove /dev/ad0s2 The 'mylabel' you pass has two purposes: first, it identifies the mirror set (two devices with the same label belong to the same mirror), and second, it's the name of the provider offered to devfs (the "thing that you can touch"). So, if you pass 'mylabel', you get a device /dev/mirror/mylabel. If you mirrored two MBR partitions and put a bsdlabel on the mirror, you end up with /dev/mirror/mylabela, /dev/mirror/mylabelc, and so on. Foobared things: *) If you kldunload the geom_mirror module, and you have a mirror of two MBR partitions which already contains a bsdlabel, you run into the KASSERT in geom_subr.c/g_modevent(): 'Unloaded class (%s) still has geom'. I have currently no idea how to deal with that. *) I tested a failure scenario and detached one harddisk with atacontrol, having a mirror on ad0s2 and ad2s2. This resulted in triggering a KASSERT in geom_slice.c/g_slice_access() 'g_slice_access but no consumer'. I'm not sure yet if this is really the fault of geom_mirror or rather a problem with how orphaning works. Let me know what you think. regards, le -- Lukas Ertl eMail: l.ertl@univie.ac.at UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/