scsi raid geometry high-point rocketraid 1640

[Klaus Friis Østergaard]

2007/4/30, Jerry McAllister <jerrymc at msu.edu>:
>
>
> > Hi,
> >
> > I have a raidcontroller high-point 1640 with 4 disks of 400 GB in a raid
> 5
> > array given me 1200 GB. The bios utility of the controller zero build
> the
> > array with 64 kb
> >
> > FDISK says that the geometry is 145923/255/63 and it is incorrect. Then
> it
> > says that for scsi it is the translation mode the raid controller is
> using.
>
> Usually you want to accept what fdisk does.  Just make the slices
> that you want.   Geometry is virtual on these systems.
>
> >
> > How do I find this?
> >
> > If I continue with the defaults I only get 1144654 MB like missing 100
> GB.
>
> Well, I would expect you to get something less than 1,490 GB just from
> the difference between the manufacturer use of GB (1,000,000,000 Bytes)
> and the way the OS uses GB (1,073,741,824 Bytes).


That is the missing link, the raid controller says 1200 GB if recalculated,
using 1.073741824 it gives  1,117.59  GB  multiplied by 1024 it gives
1144409 MB which is what FDISK gives default.

I don't know how much the raidcontroller eats up to manage
> the raid.  Raid 5 takes a piece for its redundancy/error
> correction.  A raid 5 would eat at least 20% and maybe up to 30% if it
> is rather inefficient.


WIth 4 disks it is 25% as 4th disk make the redundancy.

After that you will lose some because of inconvenient remnants of space
> that doesn't get used.   Then, there are amounts for superblocks and other
> aspects of building a filesystem, etc.  I think that tends to be around
> 10%
> altogether.
>
> So, your number seems somewhat probable, offhand, without detailed
> calculations.
>
> What operations did you do to get to that point?   Mine would be an
> fdisk that makes one slice of the entire device, a bsdlabel that
> divides the slice in to about 6 partitions (including swap) and
> a newfs on each partition except swap.


I only need the array only for one big slice and one partition for data
storage.


Thanks for the help
-- 
Klaus F. Østergaard, <farremosen(at)gmail dot com>