After my first summary I got two replies from Ronald D. Bowman ,Robert
Honore, and I asked something to Robert Honore again, both three mails are
summarized below, hope this helps Xinu Smv, too. Thanks to Ronald Bowman
and Robert Honore.
What I did ? First I tried to find the files by tag2name and I found some
of them but I could not replace them, because it was "nonrecoverable error
, hardware problem " Then I vdumped everything, by scu's commands like
show defects all, verify media, format defects all etc. and by their
various combinations I formatted the disk. Then verified again , and this
time I received no errors. Then, restarted everything from the beginning
by labelling disk, creating fdmns and fsets ,etc. Then I vrestored
everything back to the disk. Now, I receive no error messages in
/var/adm/messages , uerf reports nothing since yesterday, everything looks
ok. Here are the replies I received :
From: Ronald D. Bowman <rdbowma_at_tsi.clemson.edu>
Hi Mirat -
Here is some more information you may want to consider.
Using the scu utility can be a big help in determining the
status of a disk. All disks come with bad blocks, and during the
formatting of a disk, these are labeled and you never know about
them. What is nice is that marking of bad blocks continues
as the disk is used. One way to see how many bad blocks there
are is to use
scu> show defects all (I think this is the command).
The best thing to do with scu is find where the help page is
located(directory should be listed from the man page). this help
manual is long.
You can then do what other people are talking about with reassign.
Also, you can force a check on the entire disk by using
scu> verify (there is something else that goes here)
If you want to see some more detailed better write ups,
search for my name (Ronald D. Bowman) in the archives.(see below )
Before replacing the disk, I would check to see how many new defects
have occurred. If it is a few, then the disk is probably okay.
f there are several, then replacing the disk is better done while
it is still functional. It is much easier to put a new disk into
a system, partition it, and then copy partitions from disk to disk.
From: Robert Honore <robert_at_digi-data.com>
It is possible to find the affected file, but is a somewhat laborious process.
Here is what you need to do.
(1) Using the showfsets command, find the fileset and filedomain that matches
the fileset ID referenced in "setId 0x31a45b2b.000a0d70.1.8001". You will
probably need to do this once for each filedomain you have on your system.
(2) Having determined what fileset and filedomain contains the affected file,
you must now cd to the mount-point directory upon which the fileset was mounted
and use the /sbin/advfs/tag2name command to determine the filename of the
affected file. Verify this afterwards by using the showfile <filename> command
and verify that its tag corresponds to the one mentioned in the error message.
>MY NOTE(Mirat) :Main point here is , tag numbers in the log files and tag
>numbers of output of tag2name command are hexadecimal numbers where
>tag2name command itself accepts inputs as decimal numbers, this was from
>Robert's third mail.
To determine which disk is affected you can use the showfdmn <domain> command.
I really would suggest migrating your data off that disk to a new disk as soon
as possible.
Yours sincerely,
Robert Honore.
From: Robert Honore <robert_at_digi-data.com>
> How silly of me! What I needed to tell you was that the Id field of the output
> of the showfile command is in hexadecimal notation. The actual tag is the
> leftmost set of numbers up to the ".". Additionally, the tag you would see in
> the message is also in hexadecimal notation. Therefore you will need to convert
> the tag as it appears in your error message to decimal notation to feed it to
> the tag2name command. When tag2name gives you the pathname, you can then use
> the showfile <pathname> command. From this you must extract the tag again (the
> leftmost set of numbers up to the dot in the Id field) and convert that to
> decimal to compare.
>
> If it is at all recoverable, you may attempt to use the /sbin/advfs/salvage
> <pathname> to try and recover that file's data. Check out the man pages for the
> salvage command for more options. Again, I would really recommend replacing
> that disk.
>
> Yours sincerely,
> Robert Honore.
>
Received on Thu May 13 1999 - 08:52:43 NZST