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