I'm working with a 2.0 i386 machine.  It's got a "hardware" (presumably
really firmware) RAID card:

twe0 at pci3 dev 1 function 0: 3ware Escalade
twe0: interrupting at irq 10
twe0: 12 ports, Firmware FE7S 1.05.00.065, BIOS BE7X 1.08.00.048
twe0: Monitor ME7X 1.01.00.038, PCB Rev5    , Achip 3.20    , Pchip 1.30-66 

It's got 12 disks on it, each 286168 MB (according to the list in
dmesg - they're sold as 300G, but tha's disk-manufacturer gigabytes).
Because it has a hard limit of 2T on a RAID 5, I've configured it with
two RAID 5s, each six disks, and was planning to paste them together in
software.  And the two arrays show up fine at boot time:

ld0 at twe0 unit 0: 64K stripe RAID5, status: Normal
ld0: 1397 GB, 182405 cyl, 255 head, 63 sec, 512 bytes/sect x 2930351360 sectors
ld1 at twe0 unit 6: 64K stripe RAID5, status: Normal
ld1: 1397 GB, 182405 cyl, 255 head, 63 sec, 512 bytes/sect x 2930351360 sectors

But I've tried ccd and I've tried RAIDframe RAID0, and in each case,
two components each 2930351232 sectors adds up to a result having only
1565734912 sectors (that's the RAIDframe value, ccd may differ slightly
but is about the same) - both appear to be using 32-bit sector numbers.

Is there any way to get what I want here (a 3T filesystem)?  Would it
be enough to go through the ccd driver and replace 32-bit types with
daddr_t wherever suitable, or is there something more fundamental that
would break?  I feel competent to do that to ccd, though I wouldn't
feel competent to do it to RAIDframe.

Switching to something newer than 2.0 might be an option (this is
$DAYJOB's machine, not mine - I *wish* I had that kind of disk space!);
if this stuff has been fixed since then, I'd appreciate hearing.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B