In article <20060804162105.AFB6B32603@cs.usask.ca>,
Greg Oster  <oster@cs.usask.ca> wrote:
>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.. :( 
>

I've added the wedges ioctls and glue to the raidframe code but I cannot
test them.

christos