From owner-freebsd-stable@FreeBSD.ORG Wed Jan 2 19:47:19 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 378A016A421 for ; Wed, 2 Jan 2008 19:47:19 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.freebsd.org (Postfix) with ESMTP id 0DDB713C45B for ; Wed, 2 Jan 2008 19:47:19 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (jn@ns1 [69.55.238.237]) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id m02Jl6QV074089; Wed, 2 Jan 2008 14:47:06 -0500 (EST) (envelope-from lists@jnielsen.net) Received: (from www@localhost) by ns1.jnielsen.net (8.12.9p2/8.12.9/Submit) id m02Jl6cU074088; Wed, 2 Jan 2008 14:47:06 -0500 (EST) (envelope-from lists@jnielsen.net) X-Authentication-Warning: ns1.jnielsen.net: www set sender to lists@jnielsen.net using -f Received: from nc-2wac-zop07.wachovia.com (nc-2wac-zop07.wachovia.com [162.111.235.18]) by newwebmail.jnielsen.net (Horde MIME library) with HTTP; Wed, 02 Jan 2008 14:47:06 -0500 Message-ID: <20080102144706.6akwgph1s8s0k888@newwebmail.jnielsen.net> Date: Wed, 02 Jan 2008 14:47:06 -0500 From: John Nielsen To: "Chris H." 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> In-Reply-To: <20080102084743.xtecj951wogwws8w@webmail.1command.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) / FreeBSD-4.9 X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on ns1.jnielsen.net X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: 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 19:47:19 -0000 Quoting "Chris H." : > Quoting John Nielsen : > >> I'm not sure I remember everything from earlier in this thread so I >> don't know if it's relevant, BUT you can't boot from a gstripe >> volume (or from a gconcat one AFAIK). Inferring from your fstab >> example below it doesn't sound like you intend to but I just wanted >> to be sure. > > Are you sure? I read that using gmirror requires /kernel to be located > in the /boot slice and everything else (all other slices) can be mirrored > safely. But in all my reading (man pages, FBSD handbook, asstd articles) > I haven't seen anything indicating booting wasn't possible from a gstripe > 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 (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. :) JN > For the record, FSTAB (on da3): > > /dev/da3s1b > none (swap) > > /dev/da3s1a > / > > /dev/da3s1d > /var > > Thanks for your response. > > Chris > >> >> Quoting John Nielsen : >> >>> Quoting "Chris H." : >>> >>>> Quoting "Chris H." : >>>> >>>>> Hello, >>>>> I seem to remember a similar question being asked in the past. But never >>>> ---8<---snip---8<--- >>>>> I had originally intended to create a raid mirror on the whole >>>>> lot of HD's >>>>> during the install process. But I wasn't presented, nor could I find that >>>>> option during install. So, due to lack of time, pushed it off till later, >>>>> and simply installed onto the one HD. Now to my question(s)... >>>>> >>>>> Where is the option to create, and install to a gMIRRORED drive-set? >>>> ---8<---snip---8<--- >>>>> 2) In my cases above, I'm interested in RAID-0 (mirroring for /volume/ >>>>> not redundancy). >>>>> >>>> >>>> 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 >>> >>>> Thank you for all your time and consideration. >>>> >>>> Chris >>>> >>>> P.S. I know this is a bit noisy. I intend to keep it brief. >>>> Thank you for your understanding. :) >>>> >>>>> -- >>>>> panic: kernel trap (ignored) >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> freebsd-stable@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >>>>> >>>> >>>> -- >>>> panic: kernel trap (ignored) >>>> >>>> >>>> >>>> _______________________________________________ >>>> freebsd-stable@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >>>> >>>> >>> >>> >>> >> >> >> > > > > -- > panic: kernel trap (ignored) > > > >