Matthias Drochner writes:
> 
> mk@kilbi.de said:
> > Both do not change the limited (1666108800) size/usage of raid0, the
> > kernel still maintains its (wrong) idea of the (imited) disk size.
> 
> You've got 2 problems (at least:-):
> 1. The rf driver clips the disk size to a 32-bit value:
>    hex(10256043392) = 2634ECD80
>    dec(634ECD80) = 1666108800
>    As I see it, on a 64-bit system it should be mostly harmless,
>    just warnings, as long as you avoid the disklabel.
>    (The "size_t" in sc_size is clearly a mistake, appearently copied
>    from cgd/dksubr. But that would affect 32-bit systems only.)

good catch...  The only place sc_size gets used though is in checking 
the validity of an existing disklabel, so if no label is used, sc_size
shouldn't get in the way... (raidPtr->totalSectors is a 64-bit value...)

> 2. newfs looks at the disklabel. If there isn't a physical one, it gets
>    the default one with the values clipped as written above.
>    You could try with the "-F" flag.

It'll get clipped in raidgetdefaultlabel() with this:

 lp->d_secperunit = raidPtr->totalSectors;

where the former is explicitly 32-bits, and the latter 64. :(
So sc_size can be fixed easily, but the d_secperunit is where we 
really get bitten.. :( 

Later...

Greg Oster