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... ===================================================== 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 --- * Origin: Christ died for our sins, so let's not disappoint him. (2:2437/24.1) .