Re: <No Subject Supplied>
Posted in 1993
In article <23tmrtINNn28@emory.mathcs.emory.edu> carlton@alexis.attmail.com writes: >I'm running OnLine 5.0 UC1 on an AT&T StarServer E with Sys V Rel 4.0 2.1, >and have several scsi controllers in the machine. All my dbspaces use >"raw" disk slices and are mirrored across to a drive on another controller. >I noticed the following message on the console of this machine --apparently >from the O/S-- just a little while ago: > > WARNING: SD01 I/O Error ha0tc5 Unit 0 Error 6dd03002 block 0x00051386 > Count 16384 Sense key 0x0000003 Extended Sense 0x0000011 Op code > 0x0000028 > > WARNING: SD01 Data from block 0x00051386 is not readable. Data from this > block has been lost. An alternative block has been assigned. > >I checked my engine log and there weren't any errors reported nor were any >of the dbspaces on that drive taken off-line by the engine. >My questions are as follows: > >1. If in fact there was a bad block, why did the O/S catch it and not the > engine? Why didn't the engine report back a read or write failure? Of course not -- the O/S intercepted the failure, and OnLine never knew anything went wrong. The O/S returned a success indication to OnLine. >2. If the data was in fact lost as the message indicates, why didn't the > engine take the drive off-line and kick the mirror into production? OnLine didn't know that anything went wrong. Unless the O/S returns a -1 from the read or write attempt, OnLine must assume that everything is OK. >3. If an alternate block was assigned, has the dbspace allocation structures > been updated to reflect the new free list etc. so the engine doesn't > try to write over a now used block? It's not a question of "writing over" a block you need to worry about, it's the fact that data *isn't there* anymore that could cause you a problem. >4. Have similar changes occured within the mirror? Is it still an exact > duplicate bitmap of the production drive or are the two now out of > sink because the production has data stored in one (relative) area of the > dbspace and the mirror store in another (relative) area of the mirror > dbspace? Potentially, they could be out of sync. To be safe, you could have taken the referenced chunk down, then brought it back up so that it could re-sync from the "good" drive. The "bad" block would have been marked as such instantly, so when you go to re-use that device, addressing of that block would be rerouted to the substitute block by the O/S. >Any help appreciated. > >Carlton Doe >Spectrum Field Services Hope this helps. -- Alan Denney aland@informix.com {pyramid|uunet}!infmx!aland Disclaimer: Sender under influence of 1,3,7-trimethylxanthine "What's the use of somebody who doesn't wonder? It's the hallmark of our species that we are continually wondering what is going on." - John Dobson, S.F. Sidewalk Astronomers