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?
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.
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?
Sysop: | digital man |
---|---|
Location: | Riverside County, California |
Users: | 1,028 |
Nodes: | 17 (0 / 17) |
Uptime: | 181:07:39 |
Calls: | 503,706 |
Calls today: | 9 |
Files: | 158,903 |
D/L today: |
13,794 files (4,213M bytes) |
Messages: | 444,341 |
Posted today: | 2 |