Thanks for your reply. No, the disk is not being used for booting at all, just data storage. The RAID capacity is about 547GB, so the 1TB limit is not an issue either. The RAID is managed using a Fibre-Channel controller (if that makes any difference).
The embedded system creates a FAT32 partition on the RAID and does not support a Solaris label in sector/block 0. When the RAID is viewed by Solaris (without the Solaris label), the disk appears to be truncated to a much smaller drive, which corresponds to Solaris defaulting it to 255 heads, 63 sectors and whatever number of cylinders it calculates by dividing tha actual number of sectors by 255 and 63 ... resulting in a value that overflows the number of cylinders variable (a 16 bit unsigned int). While trolling through OpenSolaris code, the "matching" logic to the observed behaviour was found in cmlb.c, hence the post to verify if the analysis was correct and whether the intended fix in OpenSolaris would work on a (closed) Solaris machine. So I'm not sure that either of the issues you mentioned below are applicable in this specific instance. Thank you for indicating that several other places will need fixing in addition to the one place that was identified in the post ... I guess it's time for some other workaround to be found. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 22 January 2008 15:28 To: David KILLICK Cc: [email protected] Subject: Re: [storage-discuss] Large disk geometry overflows 16 bit unsigned int ... Are you trying to boot from this disk? If not, please use EFI label to support this disk. EFI label can support more than 1TB disk. There are two issues here: 1. Solaris can not boot from EFI labeled disk. Install team and ZFS team are working on that. 2. VTOC label can not support disk more than 1TB. My team are looking into it now. Please see my reply inline. Thanks, Roger D K 写道: > My project has encountered a problem accessing a very large RAID that is > written by an embedded system. Because the disk does not have a Solaris block > written in the very first sector of the disk, Solaris 10 is using a default > geometry of 255 heads and 63 sectors, but computes the number of cylinders by > dividing the total number of sectors by (255 * 63). This number exceeds 16 > bits, resulting in the following symptom of the problem: disk I/O encounters > a very premature end-of-media/file when attempting to perform any read/write > operation (e.g. via dd). > > After consulting the OpenSolaris source code, the source of the problem > appears to be lines 4266-4273 of usr/src/uts/common/io/cmlb.c ... the fix > being contemplated is to extend the logic to use a different combination of > default heads and sectors for exceedingly large drives, such that the > computed number of cylinders will fit into a UINT16. When a Solaris label is > written to the drive in question, the start of sector zero reads > "Ciprico-Talon2200-P347 cyl 49780 alt 2 hd 8 sec 2880", so using 8 and 2880 > as head and sector defaults is being contemplated. > > Here are the two questions I have: > > (a) Is this the only place in the Solaris code base that needs fixing, or > does similar code that will also need fixing lurk elsewhere too ? > It related to boot/format/install etc. Many other place need to fix and test. > (b) If the fix is made and compiled under OpenSolaris (aka version 11), will > the rebuilt kernel module be compatible for execution by the (closed) Solaris > (version 10) O/S of our deployment platform ? i.e. will _this_ version 11 > kernel module be backwardly compatible with the version 10 module > (/kernel/misc/sparcv9/cmlb) ? > Backward compatibility is a big issue to change the label of disk. It is much more complex than binary backward compatibility. For binary, changing in OpenSolaris will not go to S10 automatically. But once we work out a solution for VTOC, we will integrate it into s10. Another compatibility problem is how to separate the disks among different version of Solaris (Solaris with the fix and without the fix). It is OK for the old system can not read the disk with new label, but we need to make sure no data will lost while we try the disk on older system. > Any help is much appreciated. Any other ideas of how to solve the dilemma are > also welcome! Thanks. > > > This message posted from opensolaris.org > _______________________________________________ > storage-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/storage-discuss > _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
