Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!jwt!john From: john@jwt.UUCP (John Temples) Newsgroups: comp.unix.sysv386 Subject: Re: Automatic bad sector mapping (was: Re: Mapping abs sector ...) Message-ID: <1991Jun10.025527.10161@jwt.UUCP> Date: 10 Jun 91 02:55:27 GMT References: <767@dumbcat.sf.ca.us> <1991Jun09.133624.2806@virtech.uucp> Organization: Private System -- Orlando, FL Lines: 34 In article <1991Jun09.133624.2806@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes: >>Which of the 386 UNIXes do automatic bad sector mapping? >It is not a nice feature at all. At one time we were running Bell >Technologies 3.1 or so and it had automatic bad sector mapping. >This caused great headaches when a directory magically appeared with >bogus data in the middle, or an executable all of a sudden has a >block of zeros in the middle of it. The ESIX implementation catches errors while they're still "soft," i.e., the error is recoverable. So remapping occurs with no data loss, as long as the first time a sector has an error it isn't a hard error. >Our hardware at the time (also Bell Tech) had a problem with static >electricity that would cause a series of sectors to appear bad whenever >the machine was touched. You're saying that since the feature didn't handle an unusual hardware problem, it's bad? I think I'm more concerned with it handling the more likely hardware failures well. My experience with ESIX is that all errors have been caught while still soft -- my system kept right on running without a hitch. With ISC -- boom, I'm told I've got bad sectors; then the backup/mkpart/fsck/restore headache begins. I've never spent one second of my time handling bad blocks under ESIX; under ISC, hours have been wasted. >Yes, it sould be easier to map blocks, but IMHO automatic mapping is >not the answer. What if you had the option of having the driver report problems, and you had to give your OK for it to proceed with remapping? Or better yet, you could select between that mode and fully automatic mode. -- John W. Temples -- john@jwt.UUCP (uunet!jwt!john)