Analyze/Disk_Structure Utility

[da1nonly1]

Hi,

I had a serious problem on one disk in a big VAX cluster (not Alpha). Some directories were not recognized by the operating system, as if they didn’t exist (just some not all the directories of the disk). I thought it might be a good idea to use first Analyze/Disk_Structure Utility to possibly detect and later fix the problem without a need to initialize the disk and load older data from backup tapes. The system administrator tried that but it didn’t work, it was hanging. I have these questions:
1) what can the cause for the above problem(some directories not recognized)?
2) I read that Analyze/Disk_Structure Utility must be used only when the disk is write locked, what does it mean? How can you do that?

Thanks for the answers.

[Steven Schweda]

> [...] not recognized [...]

Actual commands and their actual output might
be more informative.

ANAL /DISK /REPAIR will write-lock the disk.
You don't need to do any write-locking
yourself. Write-locking the disk can annoy
users whose processes freeze for times up
to several minutes.

> didn t work, it was hanging

That could use a little more explanation,
too. Was there any disk activity? Did
CTRL/T show any I/O?

[Karl Rohwedder]

That reminds me of problems we had some time ago, when user managed it to create directory files with versions greater than 1, leads to much confusion...

regards Kalle

[Andy Bustamante]

Try $show error or $show device

You're looking for errors on the device, if a disk is failing it may begin to drop directories.

Andy

[Robert Gezelter]

da1nonly,

First, I would recommend extreme caution. It is far to easy to turn a questionable corruption issue into a loss of data incident.

Before going too far, I would carefully review my situation. "Lost directories" can be caused by many problems, some of which are:
- disk errors
- accidental RENAME commands
- creation of directory files with version numbers other than 1 (as was mentioned earlier)

First, I would investigate precisely what is happening. A full image (or physical) BACKUP of the disk would also be a good idea.

Care and deliberateness are good things in this situation, it is easy to make things worse. If there is little experience dealing with this level of problem, I would recommend seriously considering outside assistance (disclosure: Yes, we have assisted clients with this type of situation for many years).

ANALYZE without the /REPAIR will also report the problems without modifying the disk.

More details are helpful.

- Bob Gezelter, http://www.rlgsc.com

[Jan van den Ende]

da1nonly,

>>>
The system administrator tried that but it didn t work, it was hanging.
<<<

Until now I missed an important detail:
For how long was it hanging? Or, better formulation: are you SURE it was hanging. or only locking the disk (and every process using it), and very busy repairing?

Like Steven wrote, you do not need the /REPAIR for the analysys part.
But that WOULD be a very good indicator of the required time!

Measure how long it takes without /REPAIR, and then allow for 3-4 times WITH repair.

BTW, please DO make sure the process doing the repair is NOT writing something to the disk being repaired, like a nice report or some! I _HAVE_ come across that situation!

Proost.

Have one on me.

jpe

[GuentherF]

If you want avoid the /REPAIR use at least /LOCK. This way the on-disk structure (or files system for the Unixers) does no tchange underneath the ANALYZE program and thus gives a consistent view on the disk volume.

/Guenther

[comarow]

Do you have any idea what happened since last it worked?

Do you have a dir/full of any directory files?

Any hardware errors?

What kind of disk?

On what kind of controller?