gstripe on 7B4 - was: gmirror on 7B4
Chris H.
chris# at 1command.com
Wed Jan 2 14:24:53 PST 2008
Quoting John Nielsen <lists at jnielsen.net>:
> Quoting "Chris H." <chris#@1command.com>:
>
>> Quoting John Nielsen <lists at jnielsen.net>:
>>
>>> 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
>>>>
More information about the freebsd-stable
mailing list