Subj : IORB_GEOMETRY, PDSK_GETPHYSDEVICEPARAMS and 32 bit sizes
To   : all
From : Vitus Jensen
Date : Tue Jun 07 2005 03:15 am

Moin all!

11.11.2003, Vitus Jensen wrote a message to All:

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

 VJ> I think it has to do with the way VRAID.FLT fills the GEOMETRY
 VJ> structure:
 VJ>     pIorb->pGeometry->TotalSectors = pDrive->child->size;
 VJ>     pIorb->pGeometry->BytesPerSector = 512;
 VJ>     pIorb->pGeometry->Reserved  = 0;
 VJ>     pIorb->pGeometry->NumHeads  = 64;
 VJ>     pIorb->pGeometry->SectorsPerTrack   = 32;
 VJ>     pIorb->pGeometry->TotalCylinders    = pDrive->child->size / 64 /
 VJ> 32;

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

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


In 2003 I created an update to vraid.flt which removed mapping information when 
array sizes reached 64 GiB.  The assumption was that OS2DASD.DMD will use some 
intelligent method to think of an optimum mapping.  Well, look at the following 
snippet from os2dasd.dmd source (copyright IBM(tm) forget everything you are 
seeing here after closing the msg :-):

=====================<start>================================
      /* If the drive doesnt return any Geometry information other */
      /* than TotalSectors, then create a virtual geometry for     */
      /* the drive, else copy the Geometry data into the BPB.      */

      if (pGeometry->NumHeads != 0
           && pGeometry->BytesPerSector != 0
               && pGeometry->SectorsPerTrack != 0)
      {
         pBPB->BytesPerSector  = pGeometry->BytesPerSector;
         pBPB->NumHeads        = pGeometry->NumHeads;
         pBPB->SectorsPerTrack = pGeometry->SectorsPerTrack;
      }
      else
      {
         pBPB->BytesPerSector  = 512;
         pBPB->NumHeads        = 64;
         pBPB->SectorsPerTrack = 32;
      }
======================<end>=================================

So OS2DASD.DMD is itself restricting the usable array size to 64 GiB whenever 
vraid doesn't return mapping information.  vraid.flt is therefore forced to 
think of a mapping.

I know that the maximum values stored in a partition table (which has to be 
created on an array to place data there) is 256 heads and 63 sectors/track.  
This allows to use arrays up to 504 GiB in size.  I would like to use 255 
sectors/track to get nearly 2 TiB arrays, is this compatible with OS2DASD.DMD 
and/or DaniDASD.DMD?

The partition location routines in OS2DASD.DMD use only sector counts, no 
problem.  But there is some code in OS2DASD.DMD which tries to determine 
head/sector mapping from the partition table.  Comments say it's only called 
for removable devices but I can't see that test.  And I'm totally at a loss 
when I'm trying to imagine what IBM / the PC world will do once disk sizes 
reach 504 GiB.  New IOCTL to return 32 cylinder counts?  Different partition 
table layout?

Bye,
   Vitus

---
 * Origin: Win95 heisst Windows, weil es unter OS/2 im Fenster la (2:2437/24.1)

.