system@asuvax.asu.edu (Marc Lesure) (10/24/89)
I thought the 4.3-tahoe device driver for the ra disk series did bad block replacement until I started getting these error messages over and over. uda0: hard error datagram: unit 2: level 0 retry 133, lbn 555523: data error (uncorrectable ecc) (code 8, subcode 7) ra2: bad block report: 555523 ra2g: hard error reading fsbn 179952-179967 data error (uncorrectable ecc) (code 8, subcode 7) The man page for the uda says to get DEC to replace the bad block via EVRLK. Since we are not on DEC maint., is there another way of doing this? With the RM05 disks I used 'badsect', but this doesn't seem to work with the RA81. ----------------------------------------------------------------------- Marc Lesure / Arizona State University / Tempe, AZ "Between the world of men and make-believe, I can be found..." "False faces and meaningless chases, I travel alone..." "And where do you go when you come to the end of your dream?" UUCP: ...!ncar!noao!asuvax!lesure Internet: lesure@asuvax.eas.asu.edu
chris@mimsy.umd.edu (Chris Torek) (10/25/89)
In article <1008@asuvax.asu.edu> system@asuvax.asu.edu (Marc Lesure) writes: >I thought the 4.3-tahoe device driver for the ra disk series did bad block >replacement ... Nope, sorry. It was `too hard' (not to mention practically impossible to test). Maybe someday. . . . >The man page for the uda says to get DEC to replace the bad block via EVRLK. >Since we are not on DEC maint., is there another way of doing this? Steal a copy of EVRLK :-) Incidentally, I am still not sure of the name. There *is* a standalone diagnostic that will do it, though. (There may be several.) >With the RM05 disks I used 'badsect', but this doesn't seem to work with >the RA81. `bad144' is for DEC STD 144 disks (e.g., RP06, Eagle on Massbus, etc.). `badsect' should work but is not very nice. I have never used it myself. If you are really ambitious, add an ioctl to allow `replace' commands, and write a user-level program to do it. You will have to let the program write past the `end' of the disk (either via another ioctl, or by `adjusting' the size of, e.g., the c partition). The algorithm used for replacement can be found in the VMS source. (eeuck) -- `They were supposed to be green.' In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
thorinn@skinfaxe.diku.dk (Lars Henrik Mathiesen) (10/27/89)
chris@mimsy.umd.edu (Chris Torek) writes: >In article <1008@asuvax.asu.edu> system@asuvax.asu.edu (Marc Lesure) writes: >>I thought the 4.3-tahoe device driver for the ra disk series did bad block >>replacement ... >If you are really ambitious, add an ioctl to allow `replace' commands, >and write a user-level program to do it. You will have to let the >program write past the `end' of the disk (either via another ioctl, >or by `adjusting' the size of, e.g., the c partition). If you have money (on the order of $5000 for small academic sites) you could get MORE/bsd from MtXinu. It has bad block replacement for UDA controllers (good thing), NFS (er ...), support (at extra price) for HP 9000/300 machines (nice), _NO_ bad block forwarding _AT_ALL_ for SCSI disks on the HPs (grumble), and lots of other stuff to make your life more interesting. ``My only connection to MtXinu is as a paying customer.'' -- Lars Mathiesen, DIKU, U of Copenhagen, Denmark [uunet!]mcvax!diku!thorinn Institute of Datalogy -- we're scientists, not engineers. thorinn@diku.dk