Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!sgiblab!sdd.hp.com!caen!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: [386bsd]Wanted:PC Diagnostic reporting bad BLOCKS (not track/head)
Message-ID: <1992Oct6.171254.20906@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <1992Oct1.173109.5869@csx.cciw.ca> <1aqootINNo3l@roche.csl.sri.com>
Date: Tue, 6 Oct 92 17:12:54 GMT
Lines: 46
In article <1aqootINNo3l@roche.csl.sri.com> caveh@spartacus.csl.sri.com (Caveh Jalali) writes:
>note that you will have to verify that your driver *correctly* supports
>sector remapping. the original 386BSD driver does not. i've beaten mine
>into submission so that it works for me. i think there are patches
>which claim to fix sector remapping as well. my version of wd.c is
>has significant changes, so i don't think i can send diffs at this point.
The bad sector forwading code is included in the patch kit. It appears to
work for me (which is *why* it was included in the patch kit).
>another enhancement i made was to introduce the convention that sector
>#255 is a wildcard sector, such that the entire track is marked as remapped.
>this is somewhat consistent with the SCSI convention, but more importantly
>cuts down the size of your bad144 table by a factor of 17! this is significant
>since the table needs to be scanned (linearly right now!) for every disk
>transfer (generally 8K).
We actually should do what ACER did here and go to a bit vector. This should
speed it up by a factor of 8. Obviously we would alo want write-through
caching on the bad sector list so the traversal can be made in memory --
are you sure that the table isn't in core anyway? The normal LRU should
act to keep it there if it's small enough. If it isn't small enough, the
bad performace will act as incentive to get a better disk.
>one question i have about the current wd.c driver is whether it handles the
>case correctly, where a disk transfer starts on a "normal" sector, but
>either has a bad sector in the middle of the transfer or at the end.
>is the driver smart enough to split the transfer into the required 2 or 3
>sub-transfers??? could someone familiar with the current driver let me
>know, please?
By default, not it isn't; with the proper patches applied (also in the patch
kit), yes, this works.
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------