Subj : IORB_GEOMETRY, PDSK_GETPHYSDEVICEPARAMS and 32 bit sizes
To   : All
From : Vitus Jensen
Date : Tue Nov 11 2003 12:53 am

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...


=====================<start>================================
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?
======================<end>=================================


Any comments?

Bye,
  Vitus

---
* Origin: Christ died for our sins, so let's not disappoint him. (2:2437/24.1)