Solaris10U9ForX86 considers disk information such as capacities to be permanent once the disk is created. If the capacity appear to be different from the actual value, Solaris10U9ForX86 may fail to read/write disk data properly. Therefore, do not unnecessarily change LUN mappings. Meanwhile, use host LUN IDs that have never been used when mapping new LUNs.
When mapping a new LUN, consider the following three situations:
If the newly mapped LUN is a LUN on which no FDISK partition is created, and its host LUN ID has been used by other mapped LUNs, its capacity appears to be different from the actual value.
If the host LUN ID of the newly mapped LUN has not been used by other mapped LUNs, even if no FDISK partition is created on the LUN, there is no capacity inconsistency issue.
If any FDISK partitions are created on the LUN, there is no capacity inconsistency issue.
When creating FDISK partitions on a disk, Solaris10U9ForX86 stores its capacity information in its disk tag, and then writes the capacity information to the first sector. Solaris10U9ForX86 considers the disk capacity to be permanent once the disk is created. The following explains how Solaris10U9ForX86 identifies a LUN:
Solaris10U9ForX86 cannot properly obtain the capacity information from the first sector if no FDISK partition is created on the newly mapped LUN. Solaris10U9ForX86 uses either of the following two methods to obtain disk information based on the host LUN ID:
Solaris10U9ForX86 obtains disk capacity information from the system cache if the disk information is stored in the system cache. This causes capacity inconsistency.
Solaris10U9ForX86 requests users to create FDISK partitions if no information is stored in system cache. In this case, the capacity appeared is the same as the actual value.
2. If the newly mapped LUN has FDISK partitions, Solaris10U9ForX86 read the capacity information from the first sector of the disk and update the disk information in system cache. In this case, the capacity appeared is the same as the actual value.