gstripe on 7B4 - was: gmirror on 7B4

[Chris H.]

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
>>>>