what is if have: one on 80G, 1 on 250G, 1 320.You can create a RAID-Z from them, but the smallest disk is going to dictate how large the array is going to be (all disks are going to be limited by the smallest one of the bunch).
Let's say you have 3 disks, 10, 20 and 30 GB to keep things simple. When you create a RAID-Z from those it's going to be 30 GB total with 20 GB usable (the other 10 is used for data redundancy). All three disks are going to be limited to that 10GB one. So you'd be wasting 10 and 20 GB on the other two disks.
You will end up with a 3x80GB RAID-Z with 160 GB of usable space (remember, 1 disk is for redundancy).what is if have: one on 80G, 1 on 250G, 1 320.
it would be like 216.6 of space?
That's probably the better option.You will waste more energy to keep those disk running and you will get poor performance than buying two 240GB ssd disks and put them in raid1.
If you want your storage to be redundant (for reliability, excellent idea if a disk fails), you could partition your disks into slices. I think this would work:what is if have: one on 80G, 1 on 250G, 1 320.
it would be like 216.6 of space?
I think that's by far the best solution to the problem, since you get adequate redundancy, and different pools are not going to compete simultaneously for access to the same disk.you can gconcat the smaller ones and mirror with the larger one