Hej!

To add to the immense traffik of this echo a msg I can't find the answer
to.  I have no longer a testsystem for VRAID so the probable solution will
be: build a driver and let the customer do the testing.  Well, even
worldwide operating firms do it this way...


=====================================================
There is a customer of VRAID who has problems using his 120 GB disks with
it.  The disk structures itself are OK but the size of the array (111 GB)
is not correctly displayed by LVM.  LVM shows 45922 MB instead of 111458
MB.

I think it has to do with the way VRAID.FLT fills the GEOMETRY structure:

    pIorb->pGeometry->TotalSectors = pDrive->child->size;
    pIorb->pGeometry->BytesPerSector = 512;
    pIorb->pGeometry->Reserved  = 0;
    pIorb->pGeometry->NumHeads  = 64;
    pIorb->pGeometry->SectorsPerTrack   = 32;
    pIorb->pGeometry->TotalCylinders    = pDrive->child->size / 64 / 32;

TotalCylinders will get the value 0x0001B362.  45922 equals 0x0000B362.

Looking at OS2DASD.DMD source this shouldn't be a problem but when this
information is passed to LVM I find only the IOCtl
PDSK_GETPHYSDEVICEPARAMS.  This IOCtl uses a 16 bit value for Number of
Cylinders...

Is my analysis correct?  There is no other IOCtl, Cylinders have to be less
than 65536?

The "Storage DD Reference" states that a non-bootable device (an
array will never be bootable) doesn't need to supply CHS mapping.  What
will happen if remove the mapping from VRAID.FLT and that driver is used
with existing arrays containing partitions?  Will OS2DASD or LVM analyse
the MBR and use compatible mapping or will it create havoc?  Or should I
add logic to VRAID.FLT to use CHS on small/old arrays and no mapping on
large/new arrays?
=======================================================


Any comments?

Bye,
   Vitus

---