From owner-freebsd-stable@FreeBSD.ORG Wed Jan 2 22:24:53 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D07516A417 for ; Wed, 2 Jan 2008 22:24:53 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (mail.1command.com [75.160.109.226]) by mx1.freebsd.org (Postfix) with ESMTP id D4DB613C45B for ; Wed, 2 Jan 2008 22:24:52 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id m02MOiB7008065 for ; Wed, 2 Jan 2008 14:24:50 -0800 (PST) (envelope-from chris#@1command.com) Received: (from www@localhost) by mail.1command.com (8.13.3/8.13.3/Submit) id m02MOis2008064 for freebsd-stable@freebsd.org; Wed, 2 Jan 2008 14:24:44 -0800 (PST) (envelope-from chris#@1command.com) Received: from hitme.hitometer.net (hitme.hitometer.net [75.160.109.235]) by webmail.1command.com (H.R. Communications Messaging System) with HTTP; Wed, 02 Jan 2008 14:24:44 -0800 Message-ID: <20080102142444.0unir7afk800gss0@webmail.1command.com> X-Priority: 3 (Normal) Date: Wed, 02 Jan 2008 14:24:44 -0800 From: "Chris H." To: freebsd-stable@freebsd.org References: <20080102002651.r72jwx0pgk4000c8@webmail.1command.com> <20080102070518.ki0v7vxkgo0cossg@webmail.1command.com> <20080102111751.5huybrwosgs0ccos@newwebmail.jnielsen.net> <20080102112230.g7p1bj3sdck488g8@newwebmail.jnielsen.net> <20080102084743.xtecj951wogwws8w@webmail.1command.com> <20080102144706.6akwgph1s8s0k888@newwebmail.jnielsen.net> In-Reply-To: <20080102144706.6akwgph1s8s0k888@newwebmail.jnielsen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: H.R. Communications Internet Messaging System (HCIMS) 4.1 Professional (not for redistribution) / FreeBSD-5.5 Subject: gstripe on 7B4 - was: gmirror on 7B4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 22:24:53 -0000 Quoting John Nielsen : > Quoting "Chris H." : > >> Quoting John Nielsen : >> >>> I'm not sure I remember everything from earlier in this thread so I ---8<---snip---8<--- >>> to be sure. >> >> Are you sure? ---8<---snip---8<--- >> volume. > > Yes, I'm sure. In order to bootstrap the system, the BIOS needs to > know how to read the operating system from the disk. FreeBSD's own > loader also relies on BIOS calls for disk reads until the kernel is > loaded and executed. When using a hardware RAID controller its own > BIOS runs before the OS boot so it can handle disk I/O from the RAID > volumes it knows about. When using purely software RAID such as > gstripe, the computer knows nothing about any volumes, it just knows > about the individual disks. If you tell it to boot from disk 1, it > will try to boot from disk one and then choke since it will only get > at most 1 stripe's worth of contiguous useful data (the next stripe > being stored on a different disk). For gmirror this doesn't matter, > since an individual disk can be used to load the kernel without any > knowledge of RAID volumes. Nothing needs can write to the disk until > init mounts the root partition read-write (presumably using gmirror) > so the volume integrity is not affected. > > The simplest (IMO, although knowledge of fdisk, bsdlabel, newfs and > what boot blocks go where may be required, along with using > dump/restore on occasion) approach is to make / its own small > partition on a gmirror volume and then create gstripe (or whatever) > volumes from the remainder of the disks for the rest of the > mountpoints. That means you'll be handing slices or partitions to > gmirror, gstripe and friends rather than whole raw disks, but that's > okay. > > It is possible to have only /boot on the actual boot device/partition > (with the rest of / elsewhere) but in this scenario that just adds > complexity. Most of the few hundred MB that / typically requires are > in /boot anyway. > > If you want specific advice for a specific scenario you can probably > get it, but you'll have to supply some additional details. For > instance I'm still not sure if this is a new install or an upgrade Both: I was wondering why gmirror wasn't an option during sysinstall (the creation, and installation to). Which begged the question - now that it's installed... > (even after re-reading the entire thread), or if da3 is the same size > as da0-2. Doing what you describe below will blow away the existing > contents of da3 and the other disks, and/or won't be allowed if > anything on da3 is currently mounted/running. Also you should stop > saying mirror if you mean stripe or JBOD. :) Quite right. Again, my bad. I'm sorry this became so convoluted. It seemed so clear at first. But as it started a question about gmirror, and my almost immediate discovery that gmirror doesn't do RAID0, as I required. Turned it into gstripe. I thought I had managed to make the transition smoothly. But as you effectively indicated, no dice. Sorry. :( Thank you *very* much for your informative, and thoughtful replies - and patience. :) OK, in the final analysis I've decided (now that it's (7B4) installed...) I'll just keep /boot, /root (and presumably /dev) on the already available and running install disk (da3). Then perform: # gstripe label -v -s 131072 bigstripe \ /dev/da0 /dev/da1 /dev/da2 # newfs -U /dev/stripe/bigstripe # mkdir /bigstripe # mount /dev/stripe/bigstripe /bigstripe # echo 'geom_stripe_load="YES"' >> /boot/loader.conf # echo '/dev/stripe/bigstripe /bigstripe ufs rw 2 2' >> /etc/fstab # cd /var # tar cf - . | (cd /bigstripe; tar xvf - and repeating the above two lines for /bin, /compat, /dist, /entropy, /etc, /lib, /libexec, /media, /mnt, /proc, /rescue, /sbin, /sys, /tmp, and /usr moving and remaking /home. Then deleting and re-creating the above (/bin, /compat, etc...). Then modify /etc/fstab to read /dev/stripe/bigstripe / ufs rw 2 2 unmount /bigstripe mount / Done. Yes? Maybe I'm overestimating the FreeBSD file system. But this seems plausible. Thanks to everyones time, consideration (and patience). Chris > > JN > >> For the record, FSTAB (on da3): >> >> /dev/da3s1b >> none (swap) >> >> /dev/da3s1a >> / >> >> /dev/da3s1d >> /var >> >> Thanks for your response. >> >> Chris >> A *little* history, perhaps helps context... ---8<---snip---8<--- >>>>> OK, my mistake... >>>>> Seems for my application (RAID0), *gstripe* is what I should >>>>> be using. >>>>> Q: But RAID0 provides 0 redundancy. How will you cope with data loss? >>>>> A: Complete backups occur twice daily and I (we) use IP RAID0 - >>>>> eg; 2 different servers have/provide the same data, and the DNS provides >>>>> "round-robin". Thereby spreading the requests roughly equal across >>>>> both servers. >>>>> So, given my new found knowledge. I felt I should probably ask before >>>>> potentially clobbering (breaking) the server I'll be attempting this on. >>>>> Will the following accomplish my goal? >>>>> Current setup: >>>>> /dev indicates the following: >>>>> da0, da0c, da0cs1, da0s1, da0s1c >>>>> da1, da1c, da1cs1, da1s1, da1s1c >>>>> da2, da2c, da2cs1, da2s1, da2s1c >>>>> ...and the following, which FreeBSD is installed on: >>>>> da3, da3s1, da3s1a, da3s1b, da3s1c, da3s1d >>>>> All drives are of same size/make/model. >>>>> >>>>> Given the above, I intend to issue the following: >>>>> >>>>> # gstripe label -v -s 131072 bigstripe \ >>>>> /dev/da0 /dev/da1 /dev/da2 /dev/da3 >>>>> >>>>> # newfs -U /dev/stripe/bigstripe >>>>> >>>>> # mount /dev/stripe/bigstripe /bigstripe >>>>> >>>>> # echo 'geom_stripe_load="YES"' >> /boot/loader.conf >>>>> >>>>> # echo '/dev/stripe/bigstripe /bigstripe ufs rw 2 2' >> /etc/fstab >>>> >>>> Yes, this should be fine (though you may need to do a "gstripe >>>> load" near the beginning). >>>> >>>>> Or do/should I issue: >>>>> >>>>> # gconcat label -v extradisks /dev/da0 /dev/da1 /dev/da2 >>>>> >>>>> # gstripe label -v bigstripe /dev/da3 /dev/concat/extradisks >>>>> >>>>> # bsdlabel -wB /dev/stripe/bigstripe >>>>> >>>>> # newfs -U /dev/stripe/bigstripe >>>>> >>>>> # mount /dev/stripe/bigstripe /bigstripe >>>> >>>> No, assuming the disks are (roughly) the same size there's no >>>> reason to use gconcat, and in this case doing so will likely hurt >>>> performance in addition to adding complexity. gconcat is generally >>>> just for JBOD-type scenarios and it sounds like you're after RAID0 >>>> which is what gstripe is for. >>>> >>>> JN >>>>