cciss C/H/S/ info mismatch.

[Anu Mathew]

I've cciss (module ver: 2.6.10 1E3B21F2CB20EA251C44B1C) on rhel4 u3, with two RAID 1 (1+0) luns created on 4 identical drives.

cciss/c0d0: 146.80GB RAID 1(1+0)
cciss/c0d1: 146.80GB RAID 1(1+0)

All is good, except when those two LUNs are queried via a simple fdisk -l, they show slightly different C/H/S info:

# fdisk -l 2>/dev/null |grep sectors
255 heads, 63 sectors/track, 17848 cylinders
255 heads, 32 sectors/track, 35139 cylinders

Whereas they both are identical devices, why would the C/H/S info vary on the first LUN?

# blockdev --getsize /dev/cciss/c0d0
286734240
# blockdev --getsize /dev/cciss/c0d1
286734240

Have seen this behavior on rhel4u4 as well.

It is always the first device. IOW, if I've 3 similar Luns [0,1,2], 1,2 show the same c/h/s info, but 0 differs.

Oh yes, these luns were created similarly, the underlying individual drives are similar.

Any input would be much appreciated.

[Steven E. Protter]

Shalom,

You say they were created similarly. Does that mean exactly the same methodology? Any variance can result in this result.

Also, this could be a problem with BIOS. Boot the system and update the bios to the very latest and see if it goes away.

Lastly, This could be a problem in the programs you use to present your data. You may have a bug to present to bugzilla.redhat.com

SEP

[Matti_Kurkela · Accepted solution]

The first LUN is usually where the OS is installed, so it is partitioned by the Disk Druid (a component of the RedHat installation program). The other LUNs are partitioned by whichever method you choose.

With the modern disks, the primary addressing method is Logical Block Addressing, i.e. the address used to indicate where on disk something is located is just one big number.

The C/H/S geometry is a basically fiction that is maintained for backward compatibility. There can be multiple ways to generate a C/H/S geometry for a disk of particular size, as in your case. When a partition table is written to the disk, the software that writes it decides what to put in the legacy C/H/S fields. The C/H/S translation scheme chosen by the partitioning program is maintained by the OS after that.

Looks like the parameters for LUN 0 are chosen to maximize compatibility with older BIOSes and/or bootloaders with no LBA support.

If a bootloader or BIOS does not support LBA, the maximum cylinder number gets limited to 1024.

With your first geometry, the disk area that is accessible without LBA is 1024/255/63 = approximately 7.8 gigabytes. With your second geometry, the area accessible without LBA is about half of that: 1024/255/32 = approximately 4 gigabytes.

If you have a very old BIOS, you must fit the partition that contains your Linux kernel (and initrd, if necessary) completely inside this limit. Usually this partition is either / (root) or /boot.

On the other hand, the geometry of 35139/255/32 is a better match to the total capacity of your disk: 35139*255*32 is exactly 286 734 240 blocks, while 17848*255*63 is 286 728 120 blocks.

The tradeoff for maximal compatibility is 6120 blocks, or about 3 megabytes.

MK