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 :-):

=====================================================
      /* 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;
      }
=======================================================

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

---