From owner-freebsd-geom@FreeBSD.ORG Sun Feb 6 00:45:54 2005 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09AB416A4CE; Sun, 6 Feb 2005 00:45:54 +0000 (GMT) Received: from merlin.alerce.com (w094.z064001164.sjc-ca.dsl.cnc.net [64.1.164.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F72D43D41; Sun, 6 Feb 2005 00:45:53 +0000 (GMT) (envelope-from hartzell@kestrel.alerce.com) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id EAA2420C7; Sat, 5 Feb 2005 16:41:20 -0800 (PST) Received: from satchel.alerce.com (w092.z064001164.sjc-ca.dsl.cnc.net [64.1.164.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) Authority" (verified OK)) by merlin.alerce.com (Postfix) with ESMTP id AC31620C0; Sat, 5 Feb 2005 16:41:20 -0800 (PST) Received: from satchel.alerce.com (localhost [127.0.0.1]) by satchel.alerce.com (8.13.1/8.13.1) with ESMTP id j160jpfi004850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 Feb 2005 16:45:51 -0800 (PST) (envelope-from hartzell@satchel.alerce.com) Received: (from hartzell@localhost) by satchel.alerce.com (8.13.1/8.13.1/Submit) id j160jpdf004847; Sat, 5 Feb 2005 16:45:51 -0800 (PST) (envelope-from hartzell) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16901.26814.588055.457273@satchel.alerce.com> Date: Sat, 5 Feb 2005 16:45:50 -0800 To: freebsd-stable@freebsd.org, freebsd-geom@freebsd.org X-Mailer: VM 7.17 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid X-Virus-Scanned: ClamAV using ClamSMTP cc: Pawel Jakub Dawidek Subject: Problem with migrating onto a gmirror slice. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: hartzell@kestrel.alerce.com List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 00:45:54 -0000 I have a system that I set up to use a gmirror back in the 5.3beta days. It's running fine but I don't remember exactly how I set it up. It's a scsi system w/ two identical disks. I'd like to migrate the installation to a new box that uses ide disks, and am basing my attempts on the "GEOM mirror Approach 2: Single Slice, Preferred, More Flexible" portion of these instructions: http://people.freebsd.org/~rse/mirror/ Although the disk that I ended up with was bootable in the new system, I noticed that the slice table was messed up. After a couple of tries, here's what I've found: The machine is: FreeBSD merlin.alerce.com 5.3-RELEASE-p2 FreeBSD 5.3-RELEASE-p2 #9: Sat Dec 18 12:38:37 PST 2004 root@merlin.alerce.com:/usr/obj/usr/src/sys/MERLIN i386 Here's the series of commands that I've performed to illustrate the problem: 138 15:31 fdisk -v -B -I /dev/ad0 139 15:31 fdisk -s /dev/ad0 140 15:31 fdisk -s /dev/ad0 > ~hartzell/fdisk-initial 141 15:32 gmirror label -v -n -b round-robin disk0 /dev/ad0s1 142 15:32 fdisk -s /dev/ad0 143 15:32 bsdlabel -w -B mirror/disk0 144 15:32 bsdlabel -e mirror/disk0 145 15:33 fdisk -s /dev/ad0 146 15:34 fdisk -s /dev/ad0 > ~hartzell/fdisk-after 147 15:34 history 148 15:34 history > ~hartzell/history After the fdisk at line 138, here's the slice table: /dev/ad0: 387621 cyl 16 hd 63 sec Part Start Size Type Flags 1: 63 390721905 0xa5 0x80 The fdisk at line 142 showed that the slice table was fine after the gmirror step. But after the bsdlabels at lines 143 and 144 the slice table looks like this: /dev/ad0: 387621 cyl 16 hd 63 sec Part Start Size Type Flags 4: 0 50000 0xa5 0x80 Here's the output of "bsdlabel /dev/mirror/disk0": # /dev/mirror/disk0: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 524272 16 4.2BSD 2048 16384 32768 b: 8336976 524288 swap c: 390721904 0 unused 0 0 # "raw" part, don't edit d: 524288 8861264 4.2BSD 2048 16384 32776 e: 524288 9385552 4.2BSD 2048 16384 32776 f: 380812064 9909840 4.2BSD 2048 16384 28552 Anyone see what I'm missing? g. From owner-freebsd-geom@FreeBSD.ORG Sun Feb 6 02:12:33 2005 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 923D916A4CE; Sun, 6 Feb 2005 02:12:33 +0000 (GMT) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2211343D41; Sun, 6 Feb 2005 02:12:33 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (pool-151-199-113-125.roa.east.verizon.net [151.199.113.125]) by gromit.dlib.vt.edu (8.13.1/8.13.1) with ESMTP id j162CTuc090640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 Feb 2005 21:12:30 -0500 (EST) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (localhost.Chelsea-Ct.Org [127.0.0.1]) by zappa.Chelsea-Ct.Org (8.13.1/8.13.1) with ESMTP id j162CNYD021302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 Feb 2005 21:12:23 -0500 (EST) (envelope-from paul@gromit.dlib.vt.edu) Received: (from paul@localhost) by zappa.Chelsea-Ct.Org (8.13.1/8.13.1/Submit) id j162CMA3021301; Sat, 5 Feb 2005 21:12:22 -0500 (EST) (envelope-from paul@gromit.dlib.vt.edu) X-Authentication-Warning: zappa.Chelsea-Ct.Org: paul set sender to paul@gromit.dlib.vt.edu using -f From: Paul Mather To: Karl Denninger In-Reply-To: <20050205173326.B12620@denninger.net> References: <20050205135705.A10437@denninger.net> <20050205201237.GB1666@darkness.comp.waw.pl> <20050205170415.A12620@denninger.net> <20050205230842.GD1666@darkness.comp.waw.pl> <20050205173326.B12620@denninger.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sat, 05 Feb 2005 21:12:21 -0500 Message-Id: <1107655941.4894.29.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port cc: Pawel Jakub Dawidek cc: freebsd-geom@freebsd.org Subject: Re: Gmirror - how to do? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.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, 06 Feb 2005 02:12:33 -0000 On Sat, 2005-02-05 at 17:33 -0600, Karl Denninger wrote: > On Sun, Feb 06, 2005 at 12:08:42AM +0100, Pawel Jakub Dawidek wrote: > > On Sat, Feb 05, 2005 at 05:04:15PM -0600, Karl Denninger wrote: > > +> > Remember not to boot the main machine with this disk inside, as it can > > +> > be tasted before your main 'boot' mirror. Inserting this disk after > > +> > boot, when your 'boot' mirror is configured should be safe. > > +> > > +> Nope, won't work. > > +> > > +> The mirrors potentially have different PHYSICAL slice sizes (remember > > +> this debate a while back on this list?) and if I do this, I'm guaranteed to > > +> screw the partition table, as the fdisk size of the slice table will be > > +> picked up. > > > > Sorry, but I don't understand. > > How can you touch slices configuration by labeling ad4s1? > > > > -- > > Pawel Jakub Dawidek http://www.wheel.pl > > pjd@FreeBSD.org http://www.FreeBSD.org > > FreeBSD committer Am I Evil? Yes, I Am! > > > Won't the gmirror system create the new mirror (on the "backup disk" using > the full size of the slice? Gmirror will truncate the mirror's size to that of the smallest mirror component at creation (or, if you try and insert a provider that is too small for an existing mirror, it will [should] refuse to add it). So, if you create a slice within the mirror component (/dev/mirror/...) then it cannot, by definition, be "too big." The slice may not cover the entire drive, but it won't be bigger than the drive. The only problem you can run into is if you try and use a drive that is smaller than the smallest one used to create the initial mirror. That will not work. Cheers, Paul. -- e-mail: paul@gromit.dlib.vt.edu "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." --- Frank Vincent Zappa From owner-freebsd-geom@FreeBSD.ORG Sun Feb 6 02:18:36 2005 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CC2416A4CE for ; Sun, 6 Feb 2005 02:18:36 +0000 (GMT) Received: from FS.denninger.net (wsip-68-15-213-52.at.at.cox.net [68.15.213.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0372F43D48 for ; Sun, 6 Feb 2005 02:18:35 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net (localhost [127.0.0.1]) by FS.denninger.net (8.13.1/8.13.1) with SMTP id j162IYlm014149 for ; Sat, 5 Feb 2005 20:18:34 -0600 (CST) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net [127.0.0.1] by Spamblock-sys; Sat Feb 5 20:18:34 2005 Received: (from karl@localhost) by FS.denninger.net (8.13.1/8.13.1/Submit) id j162IThg014147; Sat, 5 Feb 2005 20:18:29 -0600 (CST) (envelope-from karl) Message-ID: <20050205201829.A14091@denninger.net> Date: Sat, 5 Feb 2005 20:18:29 -0600 From: Karl Denninger To: hartzell@kestrel.alerce.com, freebsd-stable@freebsd.org, freebsd-geom@freebsd.org References: <16901.26814.588055.457273@satchel.alerce.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <16901.26814.588055.457273@satchel.alerce.com>; from George Hartzell on Sat, Feb 05, 2005 at 04:45:50PM -0800 Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! cc: Pawel Jakub Dawidek Subject: Re: Problem with migrating onto a gmirror slice. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.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, 06 Feb 2005 02:18:36 -0000 On Sat, Feb 05, 2005 at 04:45:50PM -0800, George Hartzell wrote: > > I have a system that I set up to use a gmirror back in the 5.3beta > days. It's running fine but I don't remember exactly how I set it up. > > It's a scsi system w/ two identical disks. > > I'd like to migrate the installation to a new box that uses ide disks, > and am basing my attempts on the > > "GEOM mirror Approach 2: Single Slice, Preferred, More Flexible" > > portion of these instructions: > > http://people.freebsd.org/~rse/mirror/ > > Although the disk that I ended up with was bootable in the new system, > I noticed that the slice table was messed up. After a couple of > tries, here's what I've found: > > The machine is: > > FreeBSD merlin.alerce.com 5.3-RELEASE-p2 FreeBSD 5.3-RELEASE-p2 #9: Sat Dec 18 12:38:37 PST 2004 root@merlin.alerce.com:/usr/obj/usr/src/sys/MERLIN i386 > > Here's the series of commands that I've performed to illustrate the > problem: > > 138 15:31 fdisk -v -B -I /dev/ad0 > 139 15:31 fdisk -s /dev/ad0 > 140 15:31 fdisk -s /dev/ad0 > ~hartzell/fdisk-initial > 141 15:32 gmirror label -v -n -b round-robin disk0 /dev/ad0s1 > 142 15:32 fdisk -s /dev/ad0 > 143 15:32 bsdlabel -w -B mirror/disk0 > 144 15:32 bsdlabel -e mirror/disk0 > 145 15:33 fdisk -s /dev/ad0 > 146 15:34 fdisk -s /dev/ad0 > ~hartzell/fdisk-after > 147 15:34 history > 148 15:34 history > ~hartzell/history > > After the fdisk at line 138, here's the slice table: > > /dev/ad0: 387621 cyl 16 hd 63 sec > Part Start Size Type Flags > 1: 63 390721905 0xa5 0x80 > > The fdisk at line 142 showed that the slice table was fine after the > gmirror step. > > But after the bsdlabels at lines 143 and 144 the slice table looks > like this: > > /dev/ad0: 387621 cyl 16 hd 63 sec > Part Start Size Type Flags > 4: 0 50000 0xa5 0x80 > > Here's the output of "bsdlabel /dev/mirror/disk0": > > # /dev/mirror/disk0: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > a: 524272 16 4.2BSD 2048 16384 32768 > b: 8336976 524288 swap > c: 390721904 0 unused 0 0 # "raw" part, don't edit > d: 524288 8861264 4.2BSD 2048 16384 32776 > e: 524288 9385552 4.2BSD 2048 16384 32776 > f: 380812064 9909840 4.2BSD 2048 16384 28552 > > Anyone see what I'm missing? This is how I've done it. 1. Use "sysinstall" to do the slice table on the new disk, writing the FreeBSD "Boot Manager". QUIT Sysisntall after this (do NOT label the slice) 2. gmirror label -b round-robin disk0 ad0s1 3. bsdlabel -e /dev/mirror/disk0 Edit the label. Subtract ONE from the "c" partition size, which will be one sector too long. Write it out. If you got it right, there should be no complaints on the write. When you read it in, there should be only one (the "c") partition. 4. bsdlabel /dev/mirror/disk0 - insure that there are no complaints about the label. 5. newfs ....... each filesystem 6. Copy your filesystems over (use dump/restore, or pax) 7. Edit the /etc/fstab entries appropriately, make sure swapoff is in the /etc/rc file, etc. The result should be bootable and run. A bit different than the instructions in that page, but after fiddling with it this is the procedure I came up with, and it works. -- -- Karl Denninger (karl@denninger.net) Internet Consultant & Kids Rights Activist http://www.denninger.net My home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://www.spamcuda.net SPAM FREE mailboxes - FREE FOR A LIMITED TIME! http://genesis3.blogspot.com Musings Of A Sentient Mind From owner-freebsd-geom@FreeBSD.ORG Sun Feb 6 02:58:19 2005 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F0D916A4CE for ; Sun, 6 Feb 2005 02:58:19 +0000 (GMT) Received: from FS.denninger.net (wsip-68-15-213-52.at.at.cox.net [68.15.213.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 975A743D41 for ; Sun, 6 Feb 2005 02:58:18 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net (localhost [127.0.0.1]) by FS.denninger.net (8.13.1/8.13.1) with SMTP id j162wHCg014750 for ; Sat, 5 Feb 2005 20:58:17 -0600 (CST) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net [127.0.0.1] by Spamblock-sys; Sat Feb 5 20:58:17 2005 Received: (from karl@localhost) by FS.denninger.net (8.13.1/8.13.1/Submit) id j162wFSp014746; Sat, 5 Feb 2005 20:58:15 -0600 (CST) (envelope-from karl) Message-ID: <20050205205815.B14091@denninger.net> Date: Sat, 5 Feb 2005 20:58:15 -0600 From: Karl Denninger To: Paul Mather References: <20050205135705.A10437@denninger.net> <20050205201237.GB1666@darkness.comp.waw.pl> <20050205170415.A12620@denninger.net> <20050205230842.GD1666@darkness.comp.waw.pl> <20050205173326.B12620@denninger.net> <1107655941.4894.29.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <1107655941.4894.29.camel@zappa.Chelsea-Ct.Org>; from Paul Mather on Sat, Feb 05, 2005 at 09:12:21PM -0500 Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! cc: Pawel Jakub Dawidek cc: freebsd-geom@freebsd.org Subject: Re: Gmirror - how to do? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.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, 06 Feb 2005 02:58:19 -0000 On Sat, Feb 05, 2005 at 09:12:21PM -0500, Paul Mather wrote: > On Sat, 2005-02-05 at 17:33 -0600, Karl Denninger wrote: > > On Sun, Feb 06, 2005 at 12:08:42AM +0100, Pawel Jakub Dawidek wrote: > > > On Sat, Feb 05, 2005 at 05:04:15PM -0600, Karl Denninger wrote: > > > +> > Remember not to boot the main machine with this disk inside, as it can > > > +> > be tasted before your main 'boot' mirror. Inserting this disk after > > > +> > boot, when your 'boot' mirror is configured should be safe. > > > +> > > > +> Nope, won't work. > > > +> > > > +> The mirrors potentially have different PHYSICAL slice sizes (remember > > > +> this debate a while back on this list?) and if I do this, I'm guaranteed to > > > +> screw the partition table, as the fdisk size of the slice table will be > > > +> picked up. > > > > > > Sorry, but I don't understand. > > > How can you touch slices configuration by labeling ad4s1? > > > > > > -- > > > Pawel Jakub Dawidek http://www.wheel.pl > > > pjd@FreeBSD.org http://www.FreeBSD.org > > > FreeBSD committer Am I Evil? Yes, I Am! > > > > > > Won't the gmirror system create the new mirror (on the "backup disk" using > > the full size of the slice? > > Gmirror will truncate the mirror's size to that of the smallest mirror > component at creation (or, if you try and insert a provider that is too > small for an existing mirror, it will [should] refuse to add it). So, > if you create a slice within the mirror component (/dev/mirror/...) then > it cannot, by definition, be "too big." The slice may not cover the > entire drive, but it won't be bigger than the drive. > > The only problem you can run into is if you try and use a drive that is > smaller than the smallest one used to create the initial mirror. That > will not work. > > Cheers, > > Paul. I think you're missing what I'm trying to accomplish, and where (I think) it won't work. Given the following configuration: 1. Two internal SATA drives, each of size "X". 2. An external SATA drive bay, with two disk carriers each of size "X" (or larger) 3. An initial RAID-1 boot volume that is comprised of the two internal disks. 4. FreeBSD 5-Stable The goal is that: 1. I can and it will NOT be used, by default, by the mirror, even if the system should reboot for some odd reason. This is important, because if I screw myself in some fashion on the running machine, having the backup disk scribbled on at the same time defeats the purpose of a backup. 2. I can cause the carrier disk to be recognized, and if it is, the system will bring it current. A physical command to initiate this is acceptable (indeed, required, since I do not want that process to start unexpectedly.) 3. Once the disk in the carrier IS current, I can detach it from the running configuration and return to State #1 above. I now have a "near-line" backup that can be mounted (SEPARATELY!) at any time to recover data if for some reason there is a problem (e.g. I 'fat-finger' an "rm -rf" from a directory that I really wanted) I can also rotate these disks in the carriers so that I have an offsite copy, plus a near-line copy. 4. If the original machine takes a dump entirely (e.g. the controller or OS goes insane and scribbles on both disks, there is a physical catastrophe with the system, etc) I can take the disk in either the carrier or the safe deposit box, plug it into an arbitrary machine and boot it without drama. I could also (if I had TWO disks) boot the most current one and then bring the other into the mirror, effectively recovering both the system and the redundancy all at once. An FSCK in that instance is acceptable since I don't want to quiesce the system (which I understand is necessary to unmount/etc) Critical applications can be stopped in (3) before the disk in the carrier is detached (e.g. dbms, etc) so I know THAT data is current. The problem(s) I see with the possible ways to do this are: 1. A "gmirror remove" removes the metadata on the disk and it will no longer boot, since the root filesystem isn't on a mirror anymore (the metadata is gone). 2. A "fake out" with a gmirror label leaves me vulnerable to an unexpected resync without being prompted if the system reboots for any reason, and the possibility of the system activating the root volume. The latter could be catastrophically bad, especially if gmirror then rebuilt the STALE disk back onto the other two, immediately destroying the current data set! It leaves me with the possibility that the mirror created on that disk (if its one of the "larger" ones) is too big, and if that one is booted in recovery mode that the other backup disk could not be made part of the mirror due to it being physically smaller in block count on the same slice. In other words, whether the system is truly recoverable transparently then depends on which disk is the one you boot singly. That's not good. 3. A "gmirror deactivate" followed by a "gmirror forget" is likely (not sure yet, will test) to leave me with an unbootable disk as in (1), because while the metadata is still there it is marked "do not use"; thus, the boot will fail (I think) 4. A "atacontrol detach" leaves me with the situation where a reboot finds the disk and can leave me in exactly the same situation as (2). Something I have not tried is to: 1. Mark the mirror as "no automatic rebuilds." 2. Bring the third disk current. 3. Stop the critical processes, and perform a couple of sync's. 4. Forcibly detach it using "atacontrol detach 2". This appears to also spin the disk down. 5. Clean up the idea that there is another disk out there with "gmirror forget". I should now have a "complete" mirror set with two components, and a detached disk. Since the mirror is set "no automatic rebuilds", if the system reboots it should NOT reattach the backup volume. 6. The backup volume SHOULD be bootable on its own, without drama, as the mirror, while it will be seen as degraded, should still be operational off that volume. The only problem is that there is no way to insure any buffers for that disk have been flushed, so its very similar to a "plug pull" for an unprotected machine. I think I'll try that one next, although I don't care for the semantics. Worst thing I can get is a panic for the unexpected detach, I think :-> I can always use the disk as if it was a great big tape drive, and just dump each filesystem to it, which avoids all of this tomfoolery (maybe with a minimal system on it so I can restore the dumps onto a new set of mirrors) but while that will work, it kinda evades the purpose of what I'm trying to do - come up with a way to "hot mirror" the machine in such a fashion that recovery is painless and possible even for someone who is completely untrained, being told only to stick the backup disk into a carrier on a new CPU and turn on the power. If this sort of thing is a model that the gmirror authors didn't think of, its something they might want to in the future..... -- -- Karl Denninger (karl@denninger.net) Internet Consultant & Kids Rights Activist http://www.denninger.net My home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://www.spamcuda.net SPAM FREE mailboxes - FREE FOR A LIMITED TIME! http://genesis3.blogspot.com Musings Of A Sentient Mind From owner-freebsd-geom@FreeBSD.ORG Sun Feb 6 04:24:00 2005 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0650216A4D0 for ; Sun, 6 Feb 2005 04:23:58 +0000 (GMT) Received: from FS.denninger.net (wsip-68-15-213-52.at.at.cox.net [68.15.213.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 448E743D2F for ; Sun, 6 Feb 2005 04:23:57 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net (localhost [127.0.0.1]) by FS.denninger.net (8.13.1/8.13.1) with SMTP id j164NpV5015372 for ; Sat, 5 Feb 2005 22:23:51 -0600 (CST) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net [127.0.0.1] by Spamblock-sys; Sat Feb 5 22:23:51 2005 Received: (from karl@localhost) by FS.denninger.net (8.13.1/8.13.1/Submit) id j164NprT015370; Sat, 5 Feb 2005 22:23:51 -0600 (CST) (envelope-from karl) Message-ID: <20050205222351.A15328@denninger.net> Date: Sat, 5 Feb 2005 22:23:51 -0600 From: Karl Denninger To: Paul Mather References: <20050205135705.A10437@denninger.net> <20050205201237.GB1666@darkness.comp.waw.pl> <20050205170415.A12620@denninger.net> <20050205230842.GD1666@darkness.comp.waw.pl> <20050205173326.B12620@denninger.net> <1107655941.4894.29.camel@zappa.Chelsea-Ct.Org> <20050205205815.B14091@denninger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <20050205205815.B14091@denninger.net>; from Karl Denninger on Sat, Feb 05, 2005 at 08:58:15PM -0600 Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! cc: Pawel Jakub Dawidek cc: freebsd-geom@freebsd.org Subject: Re: Gmirror - how to do? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.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, 06 Feb 2005 04:24:00 -0000 On Sat, Feb 05, 2005 at 08:58:15PM -0600, Karl Denninger wrote: > I think you're missing what I'm trying to accomplish, and where (I think) > it won't work. > > Given the following configuration: > > 1. Two internal SATA drives, each of size "X". > 2. An external SATA drive bay, with two disk carriers each of size "X" (or > larger) > 3. An initial RAID-1 boot volume that is comprised of the two internal disks. > 4. FreeBSD 5-Stable > > The goal is that: > > 1. I can and it will NOT be > used, by default, by the mirror, even if the system should reboot for > some odd reason. This is important, because if I screw myself in some > fashion on the running machine, having the backup disk scribbled on > at the same time defeats the purpose of a backup. > > 2. I can cause the carrier disk to be recognized, and if it is, the system > will bring it current. A physical command to initiate this is > acceptable (indeed, required, since I do not want that process to start > unexpectedly.) > > 3. Once the disk in the carrier IS current, I can detach it from the > running configuration and return to State #1 above. I now have a > "near-line" backup that can be mounted (SEPARATELY!) at any time to > recover data if for some reason there is a problem (e.g. I 'fat-finger' > an "rm -rf" from a directory that I really wanted) I can also rotate > these disks in the carriers so that I have an offsite copy, plus a > near-line copy. > > 4. If the original machine takes a dump entirely (e.g. the controller > or OS goes insane and scribbles on both disks, there is a physical > catastrophe with the system, etc) I can take the disk in either the > carrier or the safe deposit box, plug it into an arbitrary machine > and boot it without drama. I could also (if I had TWO disks) boot the > most current one and then bring the other into the mirror, effectively > recovering both the system and the redundancy all at once. An FSCK in > that instance is acceptable since I don't want to quiesce the system > (which I understand is necessary to unmount/etc) Critical applications > can be stopped in (3) before the disk in the carrier is detached (e.g. > dbms, etc) so I know THAT data is current. > > The problem(s) I see with the possible ways to do this are: > > 1. A "gmirror remove" removes the metadata on the disk and it will no > longer boot, since the root filesystem isn't on a mirror anymore (the > metadata is gone). > > 2. A "fake out" with a gmirror label leaves me vulnerable to an unexpected > resync without being prompted if the system reboots for any reason, and > the possibility of the system activating the root volume. The > latter could be catastrophically bad, especially if gmirror then rebuilt > the STALE disk back onto the other two, immediately destroying the > current data set! It leaves me with the possibility that the > mirror created on that disk (if its one of the "larger" ones) is too big, > and if that one is booted in recovery mode that the other backup disk > could not be made part of the mirror due to it being physically smaller > in block count on the same slice. In other words, whether the system is > truly recoverable transparently then depends on which disk is the one > you boot singly. That's not good. > > 3. A "gmirror deactivate" followed by a "gmirror forget" is likely (not > sure yet, will test) to leave me with an unbootable disk as in (1), > because while the metadata is still there it is marked "do not use"; > thus, the boot will fail (I think) > > 4. A "atacontrol detach" leaves me with the situation where a reboot > finds the disk and can leave me in exactly the same situation as (2). > > Something I have not tried is to: > > 1. Mark the mirror as "no automatic rebuilds." > 2. Bring the third disk current. > 3. Stop the critical processes, and perform a couple of sync's. > 4. Forcibly detach it using "atacontrol detach 2". This appears to > also spin the disk down. > 5. Clean up the idea that there is another disk out there with > "gmirror forget". I should now have a "complete" mirror set with > two components, and a detached disk. Since the mirror is set "no > automatic rebuilds", if the system reboots it should NOT reattach the > backup volume. > 6. The backup volume SHOULD be bootable on its own, without drama, as the > mirror, while it will be seen as degraded, should still be operational > off that volume. > > The only problem is that there is no way to insure any buffers for that > disk have been flushed, so its very similar to a "plug pull" for an > unprotected machine. > > I think I'll try that one next, although I don't care for the semantics. > Worst thing I can get is a panic for the unexpected detach, I think :-> > > I can always use the disk as if it was a great big tape drive, and just > dump each filesystem to it, which avoids all of this tomfoolery (maybe > with a minimal system on it so I can restore the dumps onto a new set of > mirrors) but while that will work, it kinda evades the purpose of what I'm > trying to do - come up with a way to "hot mirror" the machine in such a > fashion that recovery is painless and possible even for someone who is > completely untrained, being told only to stick the backup disk into a > carrier on a new CPU and turn on the power. > > If this sort of thing is a model that the gmirror authors didn't think of, > its something they might want to in the future..... As expected, a "gmirror deactivate" leaves you with an unbootable GEOM-Mirror disk, as when you attempt to boot from that disk the system complains that the volume was marked inactive, and it is then skipped. You can mount the 'raw' disk root partition (e.g. /dev/ad4s1a), and I suspect, but do not know, if doing so and then attempting to activate the mirror would succeed or cause really bad things to happen (since you already have the slice open with the root mount.) A forcible "detach" on the SATA bus works (you can boot the resulting volume), but is extremely messy. It also leaves you with a disk that when reinserted requires a manual "insert" command. However, it has one truly ugly potential in that if the disk is in the carrier when the machine is booted, it would appear possible that any of the providers - including the "stale" one you detached - could get picked up as the 'master'. That could have truly ugly consequences. If this is all I've got available I guess I have to live with it, but forcibly ripping a bus out from under a disk seems pretty nasty to me. I suspect that for safety reasons "deactivate" will have to be the way I go, and live with the fact that a manual boot in the event of a recovery will be necessary, along with lots of care. I will run a few more tests once I have a clean third disk again with the 'deactivate' option - I suspect that I may be able to clean it up from the "fixit disk" with some care manually and then boot from it. Not ideal, but probably workable. -- -- Karl Denninger (karl@denninger.net) Internet Consultant & Kids Rights Activist http://www.denninger.net My home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://www.spamcuda.net SPAM FREE mailboxes - FREE FOR A LIMITED TIME! http://genesis3.blogspot.com Musings Of A Sentient Mind From owner-freebsd-geom@FreeBSD.ORG Sun Feb 6 19:05:11 2005 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C242C16A4CE; Sun, 6 Feb 2005 19:05:11 +0000 (GMT) Received: from merlin.alerce.com (w094.z064001164.sjc-ca.dsl.cnc.net [64.1.164.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5187243D49; Sun, 6 Feb 2005 19:05:11 +0000 (GMT) (envelope-from hartzell@kestrel.alerce.com) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id B7D0B209A; Sun, 6 Feb 2005 11:00:37 -0800 (PST) Received: from satchel.alerce.com (w092.z064001164.sjc-ca.dsl.cnc.net [64.1.164.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) Authority" (verified OK)) by merlin.alerce.com (Postfix) with ESMTP id 70397208C; Sun, 6 Feb 2005 11:00:37 -0800 (PST) Received: from satchel.alerce.com (localhost [127.0.0.1]) by satchel.alerce.com (8.13.1/8.13.1) with ESMTP id j16J58tj006042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 6 Feb 2005 11:05:08 -0800 (PST) (envelope-from hartzell@satchel.alerce.com) Received: (from hartzell@localhost) by satchel.alerce.com (8.13.1/8.13.1/Submit) id j16J58wi006039; Sun, 6 Feb 2005 11:05:08 -0800 (PST) (envelope-from hartzell) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16902.27236.71619.138367@satchel.alerce.com> Date: Sun, 6 Feb 2005 11:05:08 -0800 To: freebsd-geom@freebsd.org In-Reply-To: <16901.26814.588055.457273@satchel.alerce.com> References: <16901.26814.588055.457273@satchel.alerce.com> X-Mailer: VM 7.17 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid X-Virus-Scanned: ClamAV using ClamSMTP cc: Pawel Jakub Dawidek cc: freebsd-stable@freebsd.org Subject: Hardcoding gmirror provider [was Re: Problem with migrating...] X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: hartzell@kestrel.alerce.com List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 19:05:11 -0000 George Hartzell writes: > [...] > I'd like to migrate the installation to a new box that uses ide disks, > and am basing my attempts on the > > "GEOM mirror Approach 2: Single Slice, Preferred, More Flexible" > > portion of these instructions: > > http://people.freebsd.org/~rse/mirror/ > > Although the disk that I ended up with was bootable in the new system, > I noticed that the slice table was messed up. After a couple of > tries, here's what I've found: > > The machine is: > > FreeBSD merlin.alerce.com 5.3-RELEASE-p2 FreeBSD 5.3-RELEASE-p2 #9: Sat Dec 18 12:38:37 PST 2004 root@merlin.alerce.com:/usr/obj/usr/src/sys/MERLIN i386 > [...] I've figured out that if I hardcode the provider when I label my mirror everything seems to work out, which leaves me confused. Here's the label command I was using (modified for my situation): gmirror label -v -n -b round-robin disk0 /dev/ad0s1 After running that command, "gmirror list" tells me that the consumer for disk0 is "Name: ad0", even though I've specified ad0s1 above and when I bsdlabel the disk the slice table gets clobbered. If I do this instead: gmirror label -v -n -h -b round-robin disk0 /dev/ad0s1 then "gmirror list" tells me that the consumer is "Name: ad0s1" and bsdlabel doesn't stomp on the slice table. Am I [just] confused, and I tripping over a sharp piece of exposed code, or is this a bug. FWIW, I get the same behaviour on: FreeBSD merlin.alerce.com 5.3-RELEASE-p2 FreeBSD 5.3-RELEASE-p2 #9: Sat Dec 18 12:38:37 PST 2004 root@merlin.alerce.com:/usr/obj/usr/src/sys/MERLIN i386 and Freesbie 1.1 g. From owner-freebsd-geom@FreeBSD.ORG Sun Feb 6 19:12:11 2005 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 467C416A4CE; Sun, 6 Feb 2005 19:12:11 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id B989543D53; Sun, 6 Feb 2005 19:12:10 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 7DE26ACBD6; Sun, 6 Feb 2005 20:12:09 +0100 (CET) Date: Sun, 6 Feb 2005 20:12:09 +0100 From: Pawel Jakub Dawidek To: George Hartzell Message-ID: <20050206191209.GC1080@darkness.comp.waw.pl> References: <16901.26814.588055.457273@satchel.alerce.com> <16902.27236.71619.138367@satchel.alerce.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6zdv2QT/q3FMhpsV" Content-Disposition: inline In-Reply-To: <16902.27236.71619.138367@satchel.alerce.com> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: freebsd-stable@freebsd.org cc: freebsd-geom@freebsd.org Subject: Re: Hardcoding gmirror provider [was Re: Problem with migrating...] X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.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, 06 Feb 2005 19:12:11 -0000 --6zdv2QT/q3FMhpsV Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 06, 2005 at 11:05:08AM -0800, George Hartzell wrote: +> I've figured out that if I hardcode the provider when I label my +> mirror everything seems to work out, which leaves me confused. =20 +>=20 +> Here's the label command I was using (modified for my situation): +>=20 +> gmirror label -v -n -b round-robin disk0 /dev/ad0s1 +>=20 +> After running that command, "gmirror list" tells me that the consumer +> for disk0 is "Name: ad0", even though I've specified ad0s1 above and +> when I bsdlabel the disk the slice table gets clobbered. +>=20 +> If I do this instead: +>=20 +> gmirror label -v -n -h -b round-robin disk0 /dev/ad0s1 +>=20 +> then "gmirror list" tells me that the consumer is "Name: ad0s1" and +> bsdlabel doesn't stomp on the slice table. +>=20 +> Am I [just] confused, and I tripping over a sharp piece of exposed +> code, or is this a bug. +>=20 +> FWIW, I get the same behaviour on: +>=20 +> FreeBSD merlin.alerce.com 5.3-RELEASE-p2 FreeBSD 5.3-RELEASE-p2 #9: Sa= t Dec 18 12:38:37 PST 2004 +> root@merlin.alerce.com:/usr/obj/usr/src/sys/MERLIN i386 +>=20 +> and=20 +>=20 +> Freesbie 1.1 It happens because ad0 and ad0s1 share the same last sector. To fix this you should use '-h' option as you did or you should recreate ad0s1 slice one sector smaller. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --6zdv2QT/q3FMhpsV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFCBmwJForvXbEpPzQRAtbZAJ9U9tPkCHBSim9FgXOzZu3V+ACT2wCg7WfJ iUDuLHsMZwlok2wqdQInSnM= =Ha44 -----END PGP SIGNATURE----- --6zdv2QT/q3FMhpsV-- From owner-freebsd-geom@FreeBSD.ORG Sun Feb 6 19:21:09 2005 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2840D16A4CE; Sun, 6 Feb 2005 19:21:09 +0000 (GMT) Received: from merlin.alerce.com (w094.z064001164.sjc-ca.dsl.cnc.net [64.1.164.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE37E43D2F; Sun, 6 Feb 2005 19:21:08 +0000 (GMT) (envelope-from hartzell@kestrel.alerce.com) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id BA8B8209A; Sun, 6 Feb 2005 11:16:35 -0800 (PST) Received: from satchel.alerce.com (w092.z064001164.sjc-ca.dsl.cnc.net [64.1.164.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) Authority" (verified OK)) by merlin.alerce.com (Postfix) with ESMTP id 4CD52208C; Sun, 6 Feb 2005 11:16:35 -0800 (PST) Received: from satchel.alerce.com (localhost [127.0.0.1]) by satchel.alerce.com (8.13.1/8.13.1) with ESMTP id j16JL7L1006075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 6 Feb 2005 11:21:07 -0800 (PST) (envelope-from hartzell@satchel.alerce.com) Received: (from hartzell@localhost) by satchel.alerce.com (8.13.1/8.13.1/Submit) id j16JL713006072; Sun, 6 Feb 2005 11:21:07 -0800 (PST) (envelope-from hartzell) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16902.28195.6589.299894@satchel.alerce.com> Date: Sun, 6 Feb 2005 11:21:07 -0800 To: Pawel Jakub Dawidek In-Reply-To: <20050206191209.GC1080@darkness.comp.waw.pl> References: <16901.26814.588055.457273@satchel.alerce.com> <16902.27236.71619.138367@satchel.alerce.com> <20050206191209.GC1080@darkness.comp.waw.pl> X-Mailer: VM 7.17 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid X-Virus-Scanned: ClamAV using ClamSMTP cc: freebsd-stable@FreeBSD.org cc: "Ralf S. Engelschall" cc: freebsd-geom@FreeBSD.org Subject: Re: Hardcoding gmirror provider [was Re: Problem with migrating...] X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: hartzell@kestrel.alerce.com List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 19:21:09 -0000 Pawel Jakub Dawidek writes: > [...] > It happens because ad0 and ad0s1 share the same last sector. > To fix this you should use '-h' option as you did or you should recreate > ad0s1 slice one sector smaller. Thanks for the help! That makes sense, which is always a nice feeling. Does that mean that the instructions at: http://people.freebsd.org/~rse/mirror/ in the section labeled: GEOM mirror Approach 2: Single Slice, Preferred, More Flexible are incorrect and will result in the same kind of slice-table breakage that I was seeing or is there something going on that I'm not getting? Would it be more correct for Ralf to update the instructions to include a -h arg on his "gmirror label" step? g. From owner-freebsd-geom@FreeBSD.ORG Wed Feb 9 23:15:17 2005 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D64116A4CE for ; Wed, 9 Feb 2005 23:15:17 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD7D143D31 for ; Wed, 9 Feb 2005 23:15:16 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 51136530C; Thu, 10 Feb 2005 00:15:15 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 6C9E15308 for ; Thu, 10 Feb 2005 00:14:42 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 1001) id 6C4C7B86E; Thu, 10 Feb 2005 00:14:41 +0100 (CET) To: geom@freebsd.org From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Thu, 10 Feb 2005 00:14:40 +0100 Message-ID: <86y8dxiavz.fsf@dwp.des.no> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on flood.des.no X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,FORGED_RCVD_HELO autolearn=disabled version=3.0.1 Subject: getting a little carried away? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2005 23:15:17 -0000 this box has a RAID-1 array with a single slice containing six partitions: des@dwp ~% ls /dev/ar0* /dev/ar0 /dev/ar0s1a /dev/ar0s1c /dev/ar0s1e /dev/ar0s1g /dev/ar0s1 /dev/ar0s1b /dev/ar0s1d /dev/ar0s1f the components of ar0 are ad4 and ad6. I realize that a component in a RAID-1 array "tastes the same" to GEOM as a standalone disk, but I think this is a bit much, especially the adMcsN stuff: des@dwp ~% ls /dev/ad[46]* /dev/ad4 /dev/ad4cs1f /dev/ad4s1e /dev/ad6cs1c /dev/ad6s1b /dev/ad4a /dev/ad4cs1g /dev/ad4s1f /dev/ad6cs1d /dev/ad6s1c /dev/ad4b /dev/ad4d /dev/ad4s1g /dev/ad6cs1e /dev/ad6s1d /dev/ad4c /dev/ad4e /dev/ad6 /dev/ad6cs1f /dev/ad6s1e /dev/ad4cs1 /dev/ad4f /dev/ad6a /dev/ad6cs1g /dev/ad6s1f /dev/ad4cs1a /dev/ad4s1 /dev/ad6b /dev/ad6d /dev/ad6s1g /dev/ad4cs1b /dev/ad4s1a /dev/ad6c /dev/ad6e /dev/ad4cs1c /dev/ad4s1b /dev/ad6cs1 /dev/ad6f /dev/ad4cs1d /dev/ad4s1c /dev/ad6cs1a /dev/ad6s1 /dev/ad4cs1e /dev/ad4s1d /dev/ad6cs1b /dev/ad6s1a is this normal? more to the point, is it desirable? DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-geom@FreeBSD.ORG Wed Feb 9 23:17:24 2005 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B36016A4CE for ; Wed, 9 Feb 2005 23:17:24 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id B73AC43D1F for ; Wed, 9 Feb 2005 23:17:23 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j19NHL4U003534; Thu, 10 Feb 2005 00:17:21 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 10 Feb 2005 00:14:40 +0100." <86y8dxiavz.fsf@dwp.des.no> Date: Thu, 10 Feb 2005 00:17:21 +0100 Message-ID: <3533.1107991041@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: geom@freebsd.org Subject: Re: getting a little carried away? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2005 23:17:24 -0000 In message <86y8dxiavz.fsf@dwp.des.no>, =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= writes: >this box has a RAID-1 array with a single slice containing six >partitions: > >des@dwp ~% ls /dev/ar0* >/dev/ar0 /dev/ar0s1a /dev/ar0s1c /dev/ar0s1e /dev/ar0s1g >/dev/ar0s1 /dev/ar0s1b /dev/ar0s1d /dev/ar0s1f > >the components of ar0 are ad4 and ad6. I realize that a component in >a RAID-1 array "tastes the same" to GEOM as a standalone disk, but I >think this is a bit much, especially the adMcsN stuff: > >des@dwp ~% ls /dev/ad[46]* >/dev/ad4 /dev/ad4cs1f /dev/ad4s1e /dev/ad6cs1c /dev/ad6s1b >/dev/ad4a /dev/ad4cs1g /dev/ad4s1f /dev/ad6cs1d /dev/ad6s1c >/dev/ad4b /dev/ad4d /dev/ad4s1g /dev/ad6cs1e /dev/ad6s1d >/dev/ad4c /dev/ad4e /dev/ad6 /dev/ad6cs1f /dev/ad6s1e >/dev/ad4cs1 /dev/ad4f /dev/ad6a /dev/ad6cs1g /dev/ad6s1f >/dev/ad4cs1a /dev/ad4s1 /dev/ad6b /dev/ad6d /dev/ad6s1g >/dev/ad4cs1b /dev/ad4s1a /dev/ad6c /dev/ad6e >/dev/ad4cs1c /dev/ad4s1b /dev/ad6cs1 /dev/ad6f >/dev/ad4cs1d /dev/ad4s1c /dev/ad6cs1a /dev/ad6s1 >/dev/ad4cs1e /dev/ad4s1d /dev/ad6cs1b /dev/ad6s1a > >is this normal? more to the point, is it desirable? yes and yes. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Thu Feb 10 00:43:07 2005 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E27A516A4CE for ; Thu, 10 Feb 2005 00:43:07 +0000 (GMT) Received: from hosea.tallye.com (joel.tallye.com [216.99.199.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD2FC43D39 for ; Thu, 10 Feb 2005 00:43:06 +0000 (GMT) (envelope-from lorenl@alzatex.com) Received: from hosea.tallye.com (hosea.tallye.com [127.0.0.1]) by hosea.tallye.com (8.12.8/8.12.10) with ESMTP id j1A0h5Gf028119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 9 Feb 2005 16:43:06 -0800 Received: (from sttng359@localhost) by hosea.tallye.com (8.12.8/8.12.10/Submit) id j1A0h52O028117 for freebsd-geom@freebsd.org; Wed, 9 Feb 2005 16:43:05 -0800 X-Authentication-Warning: hosea.tallye.com: sttng359 set sender to lorenl@alzatex.com using -f Date: Wed, 9 Feb 2005 16:43:05 -0800 From: "Loren M. Lang" To: freebsd-geom@freebsd.org Message-ID: <20050210004305.GA20199@alzatex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-GPG-Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc X-GPG-Fingerprint: B3B9 D669 69C9 09EC 1BCD 835A FAF3 7A46 E4A3 280C Subject: Understanding GEOM Ranking System X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2005 00:43:08 -0000 I'm slightly confused on the ranking system use in GEOM as described in the geom(4) manpage. The wording of the description seems a little confusing, but the way I understand it is that any geom instance which has no consumers attached to anything like a disk or acd geom has a rank of 1. Any geom that does have some of it's consumers attached to a provider has a rank of the highest ranked geom providing a service to this geom. For example, a ufs filesystem is running on a raid1 configuration between partition d on slice 1 on disk ad0 mirrored with slice 2 on disk ad1 (no disklabel on second disk). This makes two disk geoms for ad0 and ad1 both with rank 1. Each disk geom has a mbr geom on top of them with rank 2 (max(1)+1). The bsd geom on slice 1 of disk ad0 has rank 3 (max(2)+1). The mirror geom on top of the bsd geom and the mbr geom on disk ad1 has a rank of 4 since max(2, 3)+1 = 4. Then a dev geom on top of the mirror geom has a rank of 5 (max(4)+1). That dev geom is what is mounted as a filesystem on freebsd. Is this correct? dev(5) ---> mirror(4) ---> bsd(3) ---> mbr(2) ---> dev(1) ---> ad0 \-------------> mbr(2) ---> dev(1) ---> ad1 -- I sense much NT in you. NT leads to Bluescreen. Bluescreen leads to downtime. Downtime leads to suffering. NT is the path to the darkside. Powerful Unix is. Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc Fingerprint: B3B9 D669 69C9 09EC 1BCD 835A FAF3 7A46 E4A3 280C From owner-freebsd-geom@FreeBSD.ORG Thu Feb 10 02:39:21 2005 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1B9116A4CE for ; Thu, 10 Feb 2005 02:39:21 +0000 (GMT) Received: from hosea.tallye.com (joel.tallye.com [216.99.199.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84E7A43D39 for ; Thu, 10 Feb 2005 02:39:20 +0000 (GMT) (envelope-from lorenl@alzatex.com) Received: from hosea.tallye.com (hosea.tallye.com [127.0.0.1]) by hosea.tallye.com (8.12.8/8.12.10) with ESMTP id j1A2dJGf029632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 9 Feb 2005 18:39:19 -0800 Received: (from sttng359@localhost) by hosea.tallye.com (8.12.8/8.12.10/Submit) id j1A2dJSo029630 for freebsd-geom@freebsd.org; Wed, 9 Feb 2005 18:39:19 -0800 X-Authentication-Warning: hosea.tallye.com: sttng359 set sender to lorenl@alzatex.com using -f Date: Wed, 9 Feb 2005 18:39:19 -0800 From: "Loren M. Lang" To: freebsd-geom@freebsd.org Message-ID: <20050210023919.GC29396@alzatex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-GPG-Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc X-GPG-Fingerprint: B3B9 D669 69C9 09EC 1BCD 835A FAF3 7A46 E4A3 280C Subject: Does geom_uzip act as a variable size storage device? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2005 02:39:21 -0000 How does the uzip geom work as a block device for a file system. My understanding of it is that it operates like a block device that trys to compress all data written to it using the same algorithm as used by pkzip and gzip. The problem I see with that is that not all data compresses by the same amount, some compresses more and other less, so a disk that acts as a compressor can hold different amounts of data depending on what's written to it. Filesystems like msdos and ufs2 don't support running on block devices of variable sizes as far as I know so how can I possibly format a uzip disk with a regular filesystem. I know that ufs supports being resized, but that's not the same as a block device that appears to be constantly changing size as data is being written to it so how does uzip work? Does it appear as some fixed size that may have wasted space if the data was able to compress really well, and when the data doesn't compress well enough, well, I don't know what would happen then. Am I just missing something here or can the uzip geom be dangerous depending on how it's used and what fs it's formatted as. -- I sense much NT in you. NT leads to Bluescreen. Bluescreen leads to downtime. Downtime leads to suffering. NT is the path to the darkside. Powerful Unix is. Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc Fingerprint: B3B9 D669 69C9 09EC 1BCD 835A FAF3 7A46 E4A3 280C From owner-freebsd-geom@FreeBSD.ORG Thu Feb 10 08:11:31 2005 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6982016A4CE for ; Thu, 10 Feb 2005 08:11:31 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACB5E43D1D for ; Thu, 10 Feb 2005 08:11:30 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j1A8BQrE003643; Thu, 10 Feb 2005 09:11:27 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Loren M. Lang" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 09 Feb 2005 16:43:05 PST." <20050210004305.GA20199@alzatex.com> Date: Thu, 10 Feb 2005 09:11:26 +0100 Message-ID: <3642.1108023086@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: freebsd-geom@freebsd.org Subject: Re: Understanding GEOM Ranking System X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2005 08:11:31 -0000 In message <20050210004305.GA20199@alzatex.com>, "Loren M. Lang" writes: >I'm slightly confused on the ranking system use in GEOM as described in >the geom(4) manpage. The wording of the description seems a little >confusing, but the way I understand it is that any geom instance which >has no consumers attached to anything like a disk or acd geom has a rank >of 1. Any geom that does have some of it's consumers attached to a >provider has a rank of the highest ranked geom providing a service to >this geom. For example, a ufs filesystem is running on a raid1 >configuration between partition d on slice 1 on disk ad0 mirrored with >slice 2 on disk ad1 (no disklabel on second disk). This makes two disk >geoms for ad0 and ad1 both with rank 1. Each disk geom has a mbr geom >on top of them with rank 2 (max(1)+1). The bsd geom on slice 1 of disk >ad0 has rank 3 (max(2)+1). The mirror geom on top of the bsd geom and >the mbr geom on disk ad1 has a rank of 4 since max(2, 3)+1 = 4. Then a >dev geom on top of the mirror geom has a rank of 5 (max(4)+1). That dev >geom is what is mounted as a filesystem on freebsd. Is this correct? > >dev(5) ---> mirror(4) ---> bsd(3) ---> mbr(2) ---> dev(1) ---> ad0 > \-------------> mbr(2) ---> dev(1) ---> ad1 Yes. In practice you should never have to think abou the ranking, it is only used to detect potential loops. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Thu Feb 10 12:44:44 2005 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E044F16A4CE for ; Thu, 10 Feb 2005 12:44:44 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 306BC43D45 for ; Thu, 10 Feb 2005 12:44:44 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id A61A2AEA62; Thu, 10 Feb 2005 13:44:34 +0100 (CET) Date: Thu, 10 Feb 2005 13:44:34 +0100 From: Pawel Jakub Dawidek To: "Loren M. Lang" Message-ID: <20050210124434.GB1400@darkness.comp.waw.pl> References: <20050210023919.GC29396@alzatex.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wzJLGUyc3ArbnUjN" Content-Disposition: inline In-Reply-To: <20050210023919.GC29396@alzatex.com> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: freebsd-geom@freebsd.org Subject: Re: Does geom_uzip act as a variable size storage device? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2005 12:44:45 -0000 --wzJLGUyc3ArbnUjN Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 09, 2005 at 06:39:19PM -0800, Loren M. Lang wrote: +> How does the uzip geom work as a block device for a file system. My +> understanding of it is that it operates like a block device that trys to +> compress all data written to it using the same algorithm as used by +> pkzip and gzip. The problem I see with that is that not all data +> compresses by the same amount, some compresses more and other less, so a +> disk that acts as a compressor can hold different amounts of data +> depending on what's written to it. Filesystems like msdos and ufs2 +> don't support running on block devices of variable sizes as far as I know +> so how can I possibly format a uzip disk with a regular filesystem. I +> know that ufs supports being resized, but that's not the same as a block +> device that appears to be constantly changing size as data is being +> written to it so how does uzip work? Does it appear as some fixed size +> that may have wasted space if the data was able to compress really well, +> and when the data doesn't compress well enough, well, I don't know what +> would happen then. +>=20 +> Am I just missing something here or can the uzip geom be dangerous +> depending on how it's used and what fs it's formatted as. You cannot write to geom_uzip's providers. So you need to create provider image (compress your file system) and geom_uzip exports it as read-only provider. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --wzJLGUyc3ArbnUjN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFCC1cyForvXbEpPzQRAurQAKDB1dGRAEi4W72TSi3vhcXtIQtGsQCfReZG f0waQgIhqt7G4TmXJzFbdU4= =ORpp -----END PGP SIGNATURE----- --wzJLGUyc3ArbnUjN-- From owner-freebsd-geom@FreeBSD.ORG Fri Feb 11 10:23:27 2005 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAE1C16A4D0 for ; Fri, 11 Feb 2005 10:23:27 +0000 (GMT) Received: from hosea.tallye.com (joel.tallye.com [216.99.199.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id 175E843D45 for ; Fri, 11 Feb 2005 10:23:25 +0000 (GMT) (envelope-from lorenl@alzatex.com) Received: from hosea.tallye.com (hosea.tallye.com [127.0.0.1]) by hosea.tallye.com (8.12.8/8.12.10) with ESMTP id j1BANOGf004644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 11 Feb 2005 02:23:24 -0800 Received: (from sttng359@localhost) by hosea.tallye.com (8.12.8/8.12.10/Submit) id j1BANNt7004642 for freebsd-geom@freebsd.org; Fri, 11 Feb 2005 02:23:23 -0800 X-Authentication-Warning: hosea.tallye.com: sttng359 set sender to lorenl@alzatex.com using -f Date: Fri, 11 Feb 2005 02:23:23 -0800 From: "Loren M. Lang" To: freebsd-geom@freebsd.org Message-ID: <20050211102323.GA4287@alzatex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-GPG-Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc X-GPG-Fingerprint: B3B9 D669 69C9 09EC 1BCD 835A FAF3 7A46 E4A3 280C Subject: NetBSD and OpenBSD label geoms. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2005 10:23:28 -0000 I have a quad-boot system with Gentoo Linux, FreeBSD, OpenBSD, and NetBSD. I was disappointed to see that none of the BSD's can see each other. (Linux could read at least 2 if not all of them.) So, I'd like to rectify that by making FreeBSD be able to read the NetBSD disklabel and then OpenBSD's disklabel. I'm thinking it will be easiest to copy the FreeBSD disklabel geom and modify it to work with NetBSD, and then merge it back into the FreeBSD disklabel code if it's still very similar. I've been looking through the disklabel data structure for both NetBSD and FreeBSD and they still seem to be very similar, in fact, maybe even identical for the typical usage. The main differnce is that netbsd seems to have replaced some of the variables with unions that include the original variable in the union. The unions are not any bigger than the original variable, and the other entries in the union seem to be for other purposes like a different filesystem than FFS. This make be believe that the only real difference between the two OSes is how the fields are interpreted. The next step I think would be for me to write a program that reads /dev/adXSY and prints out the fields so I can compare the two and see how they differ. I'd be interested to hear any thoughts others might have on this issue. Also, has there been any work on something like this before that may be useful? -- I sense much NT in you. NT leads to Bluescreen. Bluescreen leads to downtime. Downtime leads to suffering. NT is the path to the darkside. Powerful Unix is. Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc Fingerprint: B3B9 D669 69C9 09EC 1BCD 835A FAF3 7A46 E4A3 280C From owner-freebsd-geom@FreeBSD.ORG Fri Feb 11 10:45:00 2005 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58F9B16A4CE for ; Fri, 11 Feb 2005 10:45:00 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8555C43D45 for ; Fri, 11 Feb 2005 10:44:59 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j1BAiuLC009877; Fri, 11 Feb 2005 11:44:56 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Loren M. Lang" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 11 Feb 2005 02:23:23 PST." <20050211102323.GA4287@alzatex.com> Date: Fri, 11 Feb 2005 11:44:56 +0100 Message-ID: <9876.1108118696@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: freebsd-geom@freebsd.org Subject: Re: NetBSD and OpenBSD label geoms. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2005 10:45:00 -0000 In message <20050211102323.GA4287@alzatex.com>, "Loren M. Lang" writes: >I have a quad-boot system with Gentoo Linux, FreeBSD, OpenBSD, and >NetBSD. I was disappointed to see that none of the BSD's can see each >other. (Linux could read at least 2 if not all of them.) So, I'd like >to rectify that by making FreeBSD be able to read the NetBSD disklabel >and then OpenBSD's disklabel. I'm thinking it will be easiest to copy >the FreeBSD disklabel geom and modify it to work with NetBSD, and then >merge it back into the FreeBSD disklabel code if it's still very >similar. I belive all you need to do is to increase MAXPARTITIONS. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Fri Feb 11 13:40:00 2005 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B305316A4CE; Fri, 11 Feb 2005 13:40:00 +0000 (GMT) Received: from visp.engelschall.com (visp.engelschall.com [195.27.176.148]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CF3E43D58; Fri, 11 Feb 2005 13:40:00 +0000 (GMT) (envelope-from rse@engelschall.com) Received: by visp.engelschall.com (Postfix, from userid 1005) id 35B0B4CE533; Fri, 11 Feb 2005 14:40:19 +0100 (CET) Received: by en1.engelschall.com (Postfix, from userid 10000) id BE18CA17D5; Fri, 11 Feb 2005 14:39:17 +0100 (CET) Date: Fri, 11 Feb 2005 14:39:17 +0100 From: "Ralf S. Engelschall" To: George Hartzell Message-ID: <20050211133917.GA45990@engelschall.com> References: <16901.26814.588055.457273@satchel.alerce.com> <16902.27236.71619.138367@satchel.alerce.com> <20050206191209.GC1080@darkness.comp.waw.pl> <16902.28195.6589.299894@satchel.alerce.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16902.28195.6589.299894@satchel.alerce.com> User-Agent: Mutt/1.4.2.1i Organization: FreeBSD cc: freebsd-stable@FreeBSD.org cc: Pawel Jakub Dawidek cc: freebsd-geom@FreeBSD.org Subject: Re: Hardcoding gmirror provider [was Re: Problem with migrating...] X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Ralf S. Engelschall" List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2005 13:40:00 -0000 On Sun, Feb 06, 2005, George Hartzell wrote: > Pawel Jakub Dawidek writes: > > [...] > > It happens because ad0 and ad0s1 share the same last sector. > > To fix this you should use '-h' option as you did or you should recreate > > ad0s1 slice one sector smaller. > > Thanks for the help! > > That makes sense, which is always a nice feeling. > > Does that mean that the instructions at: > > http://people.freebsd.org/~rse/mirror/ > > in the section labeled: > > GEOM mirror Approach 2: Single Slice, Preferred, More Flexible > > are incorrect and will result in the same kind of slice-table breakage > that I was seeing or is there something going on that I'm not getting? > > Would it be more correct for Ralf to update the instructions to > include a -h arg on his "gmirror label" step? I've added a comment to the slice creation command that one just substract one block or alternatively use the -h option on the "gmirror label" command for hard-coding the provider. Thanks for catching this subtle problem. -- rse@FreeBSD.org Ralf S. Engelschall FreeBSD.org/~rse rse@engelschall.com FreeBSD committer www.engelschall.com From owner-freebsd-geom@FreeBSD.ORG Sat Feb 12 02:15:34 2005 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1AB516A4CE for ; Sat, 12 Feb 2005 02:15:34 +0000 (GMT) Received: from hosea.tallye.com (joel.tallye.com [216.99.199.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B3AC43D31 for ; Sat, 12 Feb 2005 02:15:34 +0000 (GMT) (envelope-from lorenl@alzatex.com) Received: from hosea.tallye.com (hosea.tallye.com [127.0.0.1]) by hosea.tallye.com (8.12.8/8.12.10) with ESMTP id j1C2FUGf007772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Feb 2005 18:15:30 -0800 Received: (from sttng359@localhost) by hosea.tallye.com (8.12.8/8.12.10/Submit) id j1C2FUqW007770; Fri, 11 Feb 2005 18:15:30 -0800 X-Authentication-Warning: hosea.tallye.com: sttng359 set sender to lorenl@alzatex.com using -f Date: Fri, 11 Feb 2005 18:15:30 -0800 From: "Loren M. Lang" To: Poul-Henning Kamp Message-ID: <20050212021530.GB1904@alzatex.com> References: <20050211102323.GA4287@alzatex.com> <9876.1108118696@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9876.1108118696@critter.freebsd.dk> User-Agent: Mutt/1.4.1i X-GPG-Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc X-GPG-Fingerprint: B3B9 D669 69C9 09EC 1BCD 835A FAF3 7A46 E4A3 280C cc: "Loren M. Lang" cc: freebsd-geom@freebsd.org Subject: Re: NetBSD and OpenBSD label geoms. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2005 02:15:35 -0000 On Fri, Feb 11, 2005 at 11:44:56AM +0100, Poul-Henning Kamp wrote: > In message <20050211102323.GA4287@alzatex.com>, "Loren M. Lang" writes: > >I have a quad-boot system with Gentoo Linux, FreeBSD, OpenBSD, and > >NetBSD. I was disappointed to see that none of the BSD's can see each > >other. (Linux could read at least 2 if not all of them.) So, I'd like > >to rectify that by making FreeBSD be able to read the NetBSD disklabel > >and then OpenBSD's disklabel. I'm thinking it will be easiest to copy > >the FreeBSD disklabel geom and modify it to work with NetBSD, and then > >merge it back into the FreeBSD disklabel code if it's still very > >similar. > > I belive all you need to do is to increase MAXPARTITIONS. I tried to create a new geom for the netbsd disklabels where all I did was change the partition id from 165 to 169 and renamed all the functions from *bsd* to *nbsd* to avoid conflicts. When I loaded the new kernel module into freebsd, it still failed to taste properly so I assume that there's some other fields that didn't add up correctly for a freebsd disklabel. I don't think that having MAXPARTITIONS would cause the taste to fail like that from my understanding of it. Also, why would netbsd change it's id from 165 to 169 if it was exactly the same? Also I'm wondering why NetBSD would change it's id from 165 to 169. Is it just because of adding more partitions or to identify it as a different OS? I was suspecting that something more critical would be different. Also, there's the issue that the d partition is a special partition in NetBSD that refers to the whole disk where the c partition is just the whole disklabel. In freebsd the c partition serves the same purpose, but for the whole disk you have to access it by other means and by-pass the disklabel. I think this is do to NetBSD deciding to make all the offsets relative to start of disk where FreeBSD has all offsets relative to start of slice containing disklabel, but I could be wrong on this. Though based off of my understanding of GEOM, the freebsd disklabel geom wouldn't even realize how big the real drive is, and it would have to be designed relative to the start of slice which is the provider that it's attached to. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. -- I sense much NT in you. NT leads to Bluescreen. Bluescreen leads to downtime. Downtime leads to suffering. NT is the path to the darkside. Powerful Unix is. Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc Fingerprint: B3B9 D669 69C9 09EC 1BCD 835A FAF3 7A46 E4A3 280C