Duplicate directory name - same version

[Robert Gezelter]

Lisa,

I cannot predict the future, but my general experience with file system problems is that they should be corrected at the earliest opportunity. Haste is dangerous, but deferral can be worse.

Data (including file systems) problems tend to cascade, with ever increasing damages. The classic "disk structure" emergency involves a situation with a corruption in the storage allocation, where blocks are included in multiple files. In that case, it is advisable to take the volume immediately out of service and sort out what happened.

In your case, I would not advise the same degree of haste, but I would deal with it promptly, while it can be a scheduled activity, rather than a emergency crisis response when something vital to your organization is impacted.

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

[LM_2]

The only reason I am asking if this is a hot issue is because if you look at the dates on the directory files - two are from 1999 and one is from 2003 so these are old problems that I just came across.

Directory VICDATAEDI:[EDI]

ROBINSON.DIR;1 4 24-OCT-1999 13:41:04.08
ROBINSON.DIR;1 4 24-OCT-1999 13:41:04.08
ROBINSON.DIR;1 1 18-JUN-2003 12:36:03.04

[Robert Gezelter]

Lisa,

I see that. My concern is based on several rather spectacular episodes I have observed at client sites (having a practice that deals with these issues create a steak stream of often not disclosable situations).

In one case, a site discovered that their backups were not usable. The investigation revealed that this had, apparently, been the situation for quite some time, but nobody had tried an emergency restore. The problem came to light when a major storage malfunction rendered the shadow copies damaged. The after effects were not pleasant.

I am not saying that this is as severe, but since we do not know the details of how this happened, or what its true side effects and implications may be, if you were my client, I would recommend that, at a minimum we:
- preserve the volume (using BACKUP/PHYSICAL or a forensic-quality imaging utility) and
- identify precisely what happened and how we can fix it.

Since these are vital data files, and the situation is longstanding, I would not recommend simply hitting it with various utilities. There is too much risk involved for that.

My US $0.02.

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

[Robert Gezelter]

Lisa,

My apologies for a typo. In my previous posting, "... steak stream ..." should have been "... steady stream ...".

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

[LM_2]

I just did an analyze/disk and at the end of the log I had some more info:
%ANALDISK-W-BAD_NAMEORDER, filename ordering incorrect in VBN 45 of directory VICDATAEDI.EDI (5132,1,1) Fil
%ANALDISK-W-BAD_NAMEORDER, filename ordering incorrect in VBN 50 of directory VICDATAEDI.EDI (5132,1,1) Fil
%ANALDISK-W-BADHEADER, file (1741,220,1) invalid file header
-ANALDISK-I-BAD_FIDSEQ, unexpected FID_SEQ field
%ANALDISK-W-BADHEADER, file (55211,402,1) invalid file header
-ANALDISK-I-BAD_FIDSEQ, unexpected FID_SEQ field
%ANALDISK-W-FREESPADRIFT, free block count of 2883753 is incorrect (RVN 1); the correct value is 2882925


Is this more info - or pretty much the same info I had with my analzye/disk/repair...?

[Robert Gezelter]

Lisa,

The references to File ID (5132,1,1) are esstentially the same.

I presume that the volume was active at the time that you were running ANALYZE. I suspect the other errors that were found resulted from the fact that the volume was active while you were checking it.

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

[Cass Witkowski]

I wonder if someone tried to edit the EDI.dir file?

[LM_2]

It just keeps getting worse.....within the vicdataedi which is actually $1$dkd202:[vicdataedi.edi] - I have a directory below this called [.com] - one of my nodes did not see this directory it said it did not exist - but if I went to another node the directory was fine and I could access it. I rebooted the node which did not see this directory and the problem was resolved. Doesn't this sound like a logical is getting deassigned - or assigned something wacky......?? If it were a disk/directory issue - wouldn't it happen on both nodes?

[Karl Rohwedder]

Lisa,

if you access the directories via logical names, I would check them on both nodes (SHOW LOGICAL [/FULL]) before doing a reboot.
If they are different,you may then want to check why.

regards Kalle

[Robert Gezelter]

Lisa,

Inconsistency is often the result of incomplete information. As I seem to recall VICDATAEDI was checked earlier and not found to be a search list (although as Karl noted, I WOULD CONFIRM that that statement is true throughout the cluster; then again, if the problem was a single logical name on one of the nodes in the cluster, you would probably not see the same behavior on the other nodes).

However, back to the subject at hand. Some symptoms can be strange because of cacheing, or other effects. Yet, a fundamental aspect of all of this is that computers are deterministic, provided we understand the complete situation. Since we often work with incomplete information, the individual situations often present diagnostically as unconnected, until the entire picture is clear.

IMHO, the first task is to correct the first set of problems without destroying the data, or disrupting operations, once the problem is corrected, we can then attempt to reconstruct or understand what happened.

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