Subject: Re: NetBSD2.0/sparc not ready for prime time?
To: None <port-sparc@NetBSD.org>
From: Eduardo Horvath <eeh@NetBSD.org>
Date: 02/14/2005 17:43:03
On Sat, Feb 12, 2005 at 12:43:18PM +0900, Henry Nelson wrote:
> On Wed, Feb 09, 2005 at 10:48:37PM +0000, Eduardo Horvath wrote:
> > 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.
All modern disks use ZBR, which means they have different numbers of
cylinders/track on different parts of the disk. The geometry returned
by the mode sense pages (on SCSI) is completely fictitious. The correct
size of the disk is gotten through the get disk capacity command which
only reports the number of sectors on the disk. The Berkeley Fast Filesystem
layout requires geometry information since it was designed to optimize
ancient disks that did not use ZBR and had a fixed geometry.
> > 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.
You do care if you try to attach a new 18GB+ disk to one of these
> > 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.
It really shouldn't make any difference. Read capacity is the command
that matters and all disks should report that correctly. If you use the
wrong geometry on a non ZBR disk you may lose a bit of performance (if
the disk does not have read/write caches and tag queuing) but that's