Quoting John Nielsen <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>:
Quoting "Chris H." <[EMAIL PROTECTED]>:
Quoting "Chris H." <[EMAIL PROTECTED]>:
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 "[EMAIL PROTECTED]"
--
panic: kernel trap (ignored)
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
--
panic: kernel trap (ignored)
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
