[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-code
Subject:    Re: [osol-code] Large disk geometry overflows 16 bit unsigned int
From:       D K <drk () mda ! ca>
Date:       2008-01-22 16:07:02
Message-ID: 7689620.1201046929152.JavaMail.Twebapp () oss-app1
[Download RAW message or body]

Thanks for your reply. The RAID is used for data storage, has a capacity of about \
547GB and is managed using a Fibre-Channel controller (if that makes any difference). \
Use of LBA would be great, but it seems that Solaris insists on using a C/H/S disk \
geometry if the platters do not contain a Solaris label. To recap ...

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

By using format(1M) we were able to write a Solaris label and successfully access the \
entire RAID, at the expense of the embedded platform's access, hence the dilemma on \
our hands.

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.

A reply on the storage-discuss forum indicates that there are many other places that \
will need fixing too and backward compatibility is no simple hurdle either ...

Thanks again for your response.
 
 
This message posted from opensolaris.org
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code


[prev in list] [next in list] [prev in thread] [next in thread]