Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!uunet!mcsun!sunic!aun.uninett.no!barsoom!barsoom!tih
From: tih@barsoom.nhh.no (Tom Ivar Helbekkmo)
Subject: 386BSD: Better bad144 handling for my WD driver.
Message-ID: <tih.715007389@barsoom>
Sender: news@barsoom.nhh.no (USENET News System)
Organization: Norwegian School of Economics
Date: Fri, 28 Aug 1992 13:09:49 GMT
Lines: 36
For those of you who have picked up my modified wd driver and stuff
from barsoom.nhh.no, here's a little change that should be put in
there (and that's in the version now on barsoom):
In wdstart(), where it scans for bad blocks, the scan through the
bad block list is performed a bit too often -- I didn't consider
the fact that wdstart() is called at interrupt-time for every
sector in a multi-sector transfer. When this happens, the scan
is not needed, and indeed can cause the driver to be too slow to
handle the transfer properly, thus dropping into one sector per
revolution mode. This is *slow*! The test at the top of the loop
should be:
#ifdef TIHBAD144
/* Check for bad sectors if we have them, and not formatting */
#ifdef B_FORMAT
if ((du->dk_flags & DKFL_BADSECT) && !(bp->b_flags & B_FORMAT) &&
((du->dk_skip == 0) || (du->dk_flags & DKFL_SINGLE))) {
#else
if ((du->dk_flags & DKFL_BADSECT) &&
((du->dk_skip == 0) || (du->dk_flags & DKFL_SINGLE))) {
#endif
The point is, of course, that if du->dk_skip is nonzero, and we're
not in single sector mode, then we've already checked these blocks.
(I noticed this when I ran Jim Bevier's new bad144 with the -s
option he added. The scan suddenly slowed to a crawl once it got
past a bad track on one of my disks -- comparing with each of those
26 block numbers for each sector remaining in the transfer just took
too much time... :-) Thanks, Jim -- good work!)
-tih
--
Tom Ivar Helbekkmo, NHH, Bergen, Norway. Telephone: +47-5-959205
Postmaster for domain nhh.no. Internet mail: tih@barsoom.nhh.no