Excerpts from dl.info-afs: 21-Dec-95 Re: Sparc20 fileserver prob.. Mark
[EMAIL PROTECTED] (1628*)
> Using a nondestructive (read) analyze may fix your problems, but if it
> doesn't, you need to vacate your disk and do a destructive (write)
> analyze. The destructive analyze is preferred since bad spots may only
> show up on writes due to voltage differences on the heads (at least so I
> hear).
An alternative to write testing is to do pattern testing, which (at
least in theory) doesn't harm data because it's a
read1-write2-read2-write1 operation. Since you'll want to pattern test
in the general area where the error occurred, using the example error
you included, you'd want to set format's "analyze" parameters something
like this:
Analyze entire disk [yes]? n
Enter starting block number [0, 0/0/0]: 1735342
Enter ending block number [2052287, 2035/13/71]: 1735442
Loop continuously [no]? y
Repair defective blocks [yes]? y
Stop after first error [no]? n
Use random bit patterns [no]? y
Enter number of blocks per transfer [101, 0/1/29]: 1
Verify media after formatting [yes]? y
Enable extended messages [no]? y
Restore defect list [yes]? y
Restore disk label [yes]? y
...and then let the pattern testing loop for a while. (Sun's Systems
Administrator manual contains more information about bad block testing,
including explanations for most of the parameters above.)
I don't think I've ever been able to find bad blocks just by doing
"read" testing, but I've been at least mildly successful in finding
using pattern testing. I've never had the pattern testing corrupt a
disk, at any rate.
James
--
James Crawford Ralston \ [EMAIL PROTECTED] \ Systems and Networks [CIS]
University of Pittsburgh \ 600 Epsilon Drive \ Pittsburgh PA 15238-2887
"Computer, you and I need to have a little talk." - O'Brien, ST:DS9
