gmirror on 7B4

[Chris H.]

Quoting John Nielsen <lists at jnielsen.net>:

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

For the record, FSTAB (on da3):

/dev/da3s1b
none (swap)

/dev/da3s1a
/

/dev/da3s1d
/var

Thanks for your response.

Chris

>
> Quoting John Nielsen <john at jnielsen.net>:
>
>> Quoting "Chris H." <chris#@1command.com>:
>>
>>> Quoting "Chris H." <chris#@1command.com>:
>>>
>>>> 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 at freebsd.org mailing list
>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>>>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>>>>
>>>
>>> -- 
>>> panic: kernel trap (ignored)
>>>
>>>
>>>
>>> _______________________________________________
>>> freebsd-stable at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>>>
>>>
>>
>>
>>
>
>
>



-- 
panic: kernel trap (ignored)