Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!nosc!ucsd!rutgers!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: mangler@csvax.caltech.edu (Don Speck)
Newsgroups: comp.sys.sun
Subject: Do I need to switch to slip sectoring?
Message-ID: <8901162132.AA22466@csvax.caltech.edu>
Date: 21 Jan 89 04:49:30 GMT
Sender: usenet@rice.edu
Organization: HHB Systems, Mawah, NJ
Lines: 25
Approved: Sun-Spots@rice.edu
Original-Date: Mon, 16 Jan 89 13:32:32 PST
X-Sun-Spots-Digest: Volume 7, Issue 115, message 10 of 18

I have six old Eagle (SMD) disks formatted without slip sectoring.  Half
were formatted under SunOS 1.1 or 2.0 and came from Sun; on the rest I set
the sector switches to match the Sun drives.  Do I need to reformat with
slip sectoring for SunOS 4.0?

I've noticed that SunOS 3.5 diag fails to change the headers of bad
sectors, resulting in "map command failed" messages.  What causes this?
Is it related to lack of slip sectors?  I can understand that the "slip"
command should fail, but why should "map" fail?  The "map" command works
in SunOS 3.2 diag.

Starting with SunOS 3.2, I noticed that diag didn't report many bad
sectors, finding only a small fraction of what our VAXen found on the same
disk.  Do recent releases of diag pay attention to correctable ECC errors
only if they can be slipped, reserving the "map" operation for only those
sectors with more blatant errors?  Or do they always ignore correctable
ECC errors?  Is this Sun's way of trying to conserve the limited number
(126) of BAD144 table slots?

Basically, I'm wondering if changing the sector switches and reformatting
is going to result in fewer undetected marginal/bad sectors, or more.

>From the 'diag' behavior I've seen, it's not an experiment that I can
undo.  Does anyone know whether slip sectoring will make diag work again,
or if SunOS 4.0 requires them?