D K wrote:
> 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 ?
>
You might want to look at format(1M).
But my first gut reaction is that you're proceeding wrongly here. Such
large devices should use LBA mode, and frankly don't need a CHS
geometry. You might want to verify whether this is even strictly
required. When I last looked at cmlb, I thought I perceived that CHS
geometry wouldn't be generated for certain disks, and this should not
create a problem. But maybe I need to look again.
> (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) ?
>
It may not be *used* by other devices. No guarantees there.
> Any help is much appreciated. Any other ideas of how to solve the dilemma are
> also welcome! Thanks.
>
See above.
- Garrett
>
>
> This message posted from opensolaris.org
> _______________________________________________
> opensolaris-code mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
>
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
