gc@vax135.UUCP (Eugene Cristofor) (05/03/85)
Are there any tools to allow updating of revectoring info for RA81/UDA50? When a new sector goes bad it should be added to the map with a relatively simple user-level program, maybe with some ioctl() calls to the driver. The only method our DEC reps can suggest is reformatting of the whole disk, after which yours truly has to restore everything form tape, which takes forever! Any insights will be appreciated! vax135!gc
rfs@ihlpl.UUCP (r. stork) (05/03/85)
> Are there any tools to allow updating of revectoring info > for RA81/UDA50? When a new sector goes bad it should be added > to the map with a relatively simple user-level program, maybe > with some ioctl() calls to the driver. > > The only method our DEC reps can suggest is reformatting of the > whole disk, after which yours truly has to restore everything > form tape, which takes forever! > > Any insights will be appreciated! > > vax135!gc You should have your DEC reps contact their next level of support for the correct procedures on dealing with the problem. The approach they are using is the ABSOLUTE worst way to deal with the problem. The reasons for this are due to the DSA Architecture. Each RA81 has a set of tables containing the bad spots found at manufacturing time. When the drive is formatted these tables are copied into another set of drive tables (working area). The DEC CE's have no tool to change the manufacturing table. Any bad spots found in formatting will be added to these tables. If you are running VMS or have hacked Bad Block Revectoring into your disk driver, this working area will dynamically grow as the operating system finds bad spots and retires them in favor of alternates (either on track or not). Good so far. One problem is that the current DEC formatting tool is a non-exhaustive formatter that will not find all the bad spots. They assumed that everyone would have BBR and DSA systems so no more powerful tool was needed in the field. The problem is that BBR is not in all flavors of UNIX, so when a new bad spot appears, you do your dump to tape, they re-format, and you restore, to the ORIGINAL manufacturers list of defects plus whatever the formatter finds. So now you likely will get all kinds of bad spots back. There is no good solution except to have BBR on your system, but here is a hack that will work. Boot up under VMS, and create a VMS filesystem that fills up the entire RA81. Write a little program that fills is up completely with files. File size should be about 64KB. Let this thing run overnight (12 hours, but you only do it once). Now run analyze on the VMS filesystem you build. This reads each file on the disk. VMS will find the bad spots and re-vector them for you. Do it again since it only takes an hour. You now have a logically free disk. Dump the filesystem to tape (30 Minutes) and save them. Now boot up UNIX and put your filesystem out on disk. Your problem is solved. The RA81` will use the tables just filled by VMS and will work fine until a new bad spot appears. When that happens simply dump your UNIX filesystem to tape as before, boot VMS and read-in the tape you made, run analyze once and restore your filesystem. This is the approach that we are using with Ra81's in my lab. It was developed after discussions with the RA81 project manager and several of DEC's technical support people. By the way, the DEC CE's did most of the VMS stuff, and keep several copies of the tapes in all the Chicago offices serving RA81's. All of the CE's in our area working on Ra81's were told NOT to format them except when the read/write board or datapath interface board had gone bad. This could then cause the bad spot tables(FCT I think.) to fill up with many bad spots and hence slow down the drive due to re-vectoring. One last point, DEC has promised that a new diagnostic will soon be available to allow the CE's to at least read the status of the drive internal tables. Hope this helps. Ron Stork ihlpl!rfs
cspencer@bbnccv.UUCP (Cliff Spencer) (05/03/85)
> Are there any tools to allow updating of revectoring info > for RA81/UDA50? Dec does have a tool to do this. It is called "rabads" and runs as a standalone program. cliff
chris@umcp-cs.UUCP (Chris Torek) (05/05/85)
There is a beta-test version of a bad block forwarding uda50 driver for
4.2BSD available from dave@riacs.ARPA. It works, mostly, though I
won't say it's the cleanest code I've ever seen. (Just today I put a
few hours into cleaning it up somewhat. What a mess... but it does
actually work.)
I don't know if the Ultrix UDA50 driver does bad block forwarding. The
one that was current as of around last June doesn't. It would be nice
if they used Dave's code (except that it doesn't work with 3Coms, but
then again DEC probably would just say "buy DEUNAs..."). By the way,
to give credit where it is due, Dave's code appears to be mostly a
combination of watrose!arwhite's and qtlon!tony's modifications of the
original 4.1BSD code (whether that came from Berkeley or elsewhere, I
know not). It would be nice if Dave's version made it into 4.3...
The current code on ucbmonet still seems to be the version by
decvax!rich and Jim Gettys, which doesn't have bad block forwarding.
(Funny, it even still has the bug which hangs udopen under the right
conditions. With a hack to get around it, no less. Yuck! Someone
should do something about this!... Why are you all looking at *me*??)
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@maryland