>Solaris 2.6 5/98, ADSM 3.1.2.20 Server - After a night of successful backups to
>the primary disk pool, during a morning Migration to tape my ADSM server began
>reporting read-errors from a specific diskpool volume...
...
>I cancelled the process in Step 1 after it had listed over 1000 damaged files.
...
> Q1. Why did the first two 'Audit Volume Fix=Yes' attempts fail ?
Use caution when approaching this kind of problem. In particular, when you
encounter this kind of disk problem, try to avoid immediately going at it from
the application (TSM) level, as you can end up wasting your time or taking an
inappropriate course of action. Instead, approach it from the operating
system level. Use whatever error log or diagnostics you need to get a sense
of what's actually wrong. Many times the electronics associated with the
drive itself have developed a fault; or there may even be something as simple
as a loose cable. In such circumstances you can get varying indications of
"bad files", which can change in repeated attempts. In fact, the files may
not themselves be bad at all - you simply can't get at them. If you can
determine that the problem is not actually a mechanical problem (platter
surface damage or sticky access arm) you may be able to regain access by
replacing the electronics portion of the drive from spare parts.
In summary: From the application level you usually don't know what the actual
problem is with the hardware, so it's best to determine that from the OS level
before deciding on the most appropriate course of action.
Richard Sims, BU
