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)

Hi Vitus,

Replying to a message of Vitus Jensen to All:

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

That's correct. Remember that that particular IOCtl dates back to the days of MS-OS/2, so it is wall-to-wall 16-bit, even though the underlying code is nowadays 32-bit.

Is my analysis correct? There is no other IOCtl, Cylinders have to be less than 65536?

Look at the OEMHLP_QUERYDISKINFO IOCtl, documented in ADDENDUM.INF. This allocates a DWORD for cylinder count in its data packet, thus allowing over 4 billion cylinders. Just be aware that the information for this query is cached from a BIOS interrupt before the kernel switches to protected mode. This means that you will need a fairly recent BIOS (and SCSI BIOS, if your array is on SCSI disks) to allow the system to collect the data.

Regards

Dave
<Team PL/I>

--- FleetStreet 1.25.1
* Origin: My other computer is an IBM S/390 (2:257/609.5)

Moin all!

11.11.2003, Vitus Jensen wrote a message to All:

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?

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)