(SUMMARY) sector slipping

From: John Valdes (valdes@geosun.uchicago.edu)
Date: Wed Aug 01 1990 - 15:21:55 CDT

Yesterday, I posted:

>We just upgraded our Xylogics 450 disk controller on our 3/160 to a 7053
>controller. We have two Fujitsu M2351 Eagles attached to it. ... The first
>drive had 83 defects and formatted properly. The second drive had 227 defects,
>but when we tried formatting it, format returned with "bad sector map table
>full" (not the exact wording), implying that format was trying to map the bad

>My question is: Can the Fujitsu M2351 handle slip sectoring, and if so, how do
>I configure the drive for slip sectoring?

The problem turned out to be with the setting of some jumpers in the M2351 which
control the number of bytes per sector.

>From what I gathered (please feel free to correct me), sector slipping is
controlled in this way. First of all, the disk controller has to support sector
slipping (all SMD controllers allow this, such as the 7053). Next, the fields
in the "disk_type" entry must be specified in such a way as to allow sector
slipping. Specifically, the number of sectors, plus 1, times the bytes per
sector must be less than or equal to the total number of bytes per track. That
is, (nsect + 1)*bps <= bpt. This way, since the number of sectors to which
data is written is given by nsect, there will be will be room on the track for
a spare sector, which can be used for slipping. The catch is that bps and bpt
must correspond to the setting in the drive (via jumpers or whatever), otherwise
these values (the ones in the drive) will be used.

In our case, we used the standard "disk_type" entry for the M2351 Eagle that
comes with the OS for our drives. This entry specifies nsect=46, bps=595, and
bpt=28160. With these values, bpt - bps*nsect = 790, which is greater than bps,
so that there's room for one spare sector on the track. However, our drive was
jumpered for bps=600, so in this case, bpt - 600*nsect = 560, which doesn't
leave enough room for a spare sector, and hence the track gets mapped instead.

Many thanks to all who responded:

Mark R. Wallen, mwallen@ucsd.edu
Daryl Crandall, daryl@dash.mitre.org
Joe Pruett, tessi!joey@nosun.West.Sun.COM

John Valdes
University of Chicago

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:05:58 CDT