Subject: Re: NetBSD2.0/sparc not ready for prime time?
To: None <port-sparc@NetBSD.org>
From: Henry Nelson <firstname.lastname@example.org>
Date: 02/12/2005 12:43:18
On Wed, Feb 09, 2005 at 10:48:37PM +0000, Eduardo Horvath wrote:
> On Thu, Feb 10, 2005 at 07:20:51AM +0900, Henry Nelson wrote:
> > Why did NetBSD's sysinst format the disk differently than Solaris? The
> > scsi probe at bootup shows the disk larger than it should be. The initial
> > installation before the Solaris format put a disk label with more user
> > available sectors than there really appear to be. I also wonder about
I should have described the situation more clearly.
The disk in question is almost 10 years old. NetBSD "sees" this disk as:
sd0 at scsibus0 target 3 lun 0: <QUANTUM, FIREBALL_TM1280S, 300X> SCSI2 0/direct fixed
sd0: 1222 MB, 6810 cyl, 2 head, 183 sec, 512 bytes/sect x 2503872 sectors
Solaris, on the other hand, sees it as having only 1217 MB. The total
cylinders is the same 6808+2. The last sector Solaris verifies is
6807/1/105, or approximately 2491572.
> NetBSD can use a native disklabel as well as a solaris disklabel.
> When the NetBSD disklabel program labels a disk it inserts a NetBSD
> disklabel and a separate Sun disklabel for OBP to use. The NetBSD
I did not write the Solaris disklabel on the disk since I intend on
installing NetBSD, no matter what. What bothers me is that NetBSD's
native disklabel had the disk larger than it really is, or at least
larger than the manufacturer intended for user data:
c: 2503872 0 unused 0 0 # (Cyl. 0 - 6841*)
> disklabel is in terms of sectors. The Sun disklabel is in terms
> of cylinders, heads, and sectors/track.
Yes, this difference is extremely significant with these old disks.
NetBSD is calculating backwards (2503872/183/2 = 6841). Solaris
calculates from the number of cylinders (6808*183*2 = 2491728). From
experience, I trust the latter. With NetBSD's disklabel, it is probably
a matter of time before such old disks will go bad. It happened on
this disk, and going back over old notes, I found that the same thing
was the most likely cause of failure of an NEC DSE2010S. In both cases,
manually writing the NetBSD disklabel based on the calculation from the
user available cylinders as described in the manufacturer's literature saved
the disk. In the case of the NEC, the damage to the tail end cylinders
(about 100) appears permanent, although with the corrected label the disk
has been running silent for about 1-1/2 years and only clacks on the last
50MB or so. This NEC was/is being used in an NEC PC9821, which uses an
offshoot of port i386. I think I caught the Quantum Fireball soon enough
because it appears to be okay; at least the noise has stopped.
> The Sun disklabel is quite limited in the size of disk it can describe.
That is not really an issue on architectures like sun4c or sun4m, which
Sun itself no longer supports.
> As far as the alternate cylinders are concerned, I don't believe
> they are actually used for anything anymore. They were originally
> for bad block reallication on the old IPI disks (I think it was
> IPI, it's been so long since I excized that code....) Sun originally
> used. But now SCSI and IDE disks do bad block reallocation in firmware.
Yep, that sounds right. Maybe I'm wrong, but I wonder if sysinst
shouldn't put up a warning about disks manufactured before around 1998.
Or, perhaps there should be code to switch calculation methods based on
the size of the disk, anything less than about 4GB is CHS with partitions
on cylinder boundaries, anything over 8GB uses sector-based calculations.
| day job: | http://yuba.kcn.ne.jp/biorec/nehan/henken.html