RESOLVED - Re: graid5 or gvinums - bootable?

Howard Goldstein hg at queue.to
Tue Aug 14 04:45:17 UTC 2007


Ulf Lilleengen wrote:
> On Sat, Aug 11, 2007 at 10:08:07PM -0500, CyberLeo Kitsana wrote:
>> Howard Goldstein wrote:
>>> Q: Should a graid5 or gvinum provider be expected to be bootable,
>>> assuming the prover's partition table has an active bootable partition
>>> containing a properly bsdlabeled 'a' slice with the /boot subdirectories
>>> in it (i.e., all of the stuff you normally need in an ordinary, non-geom
>>>  system to have a bootable slice)?
>>>
>>> Teh googling is somewhat helpful indicating that the boot loader can now
>>> deal with the GEOM'd gvinum as the boot device, and of course it works
>>> with gmirror but that's not really surprising since that provider
>>> wouldn't doesn't have its /boot slice striped into ribbons across
>>> multiple consumers like graid5 and gvinum in raid-5.
>> I haven't tried with just /boot, but I have a machine with a 1.5GB
>> mirror across four disks for the root filesystem, with a graid5 across
>> the remaining space for the other filesystems. That works just fine.
>>
>> As far as I know, however, no boot loader can understand
>> software-striped or software-raid5ed filesystems, given that it would
>> essentially need to implement the relevant geom providers itself.
>>
> Yes. This is no problem with mirrors, since it's essentially just to read the
> first sectors of it. However, the other reason is that gmirror stores it's
> metadata at the end, so the loader won't have to care about it. So, booting of a
> gvinum volume will not work, but using another partition for /boot, and gvinum for
> root should work.

What I eventually did here across three identical 320gb drives was to
set up three slices on all of the drives

s1 gmirror for /
s2 gstripe for swap and /tmp
s3 graid5 for /var and /usr

I ran into a problem though, the geometry of the onboard ICH5 RAID
controlling two of the drives turned out to be different than the 3ware
Escalade's geometry for the same drive.  This seems to have caused the
3ware controller to do unaligned i/o with a performance hit I didn't
notice until it also caused intermittent warnings for the 3ware driver
when its malloc failed.  Setting up the stripes so they all began on
cylinder boundaries for both geometries appears to have worked (at least
it's initializing the graid5 array about twice as fast as when it was
unaligned)

I wonder if I could have avoided a lot of annoying arithmetic with
looooong integers if I set the consumers up on the partitions in a
single but it seemed a bridge too far

Thanks Cyberleo and Ulf for your observations and comments



More information about the freebsd-geom mailing list