Duplicate directory name - same version

[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

[LM_2]

I am so confused anymore - I just had the same problem again and the reboot does fix it - now on the response above:

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.


With all these responses - how or what is the first set of problems to fix....???

[Robert Gezelter]

Lisa,

The first order of business is to get a PHYSICAL backup of the disk volume.

Then that copy can be used to verify/understand the problem in relative safety.

Once the correction is understood, a second PHYSICAL backup can be done (and archived). The corrective surgery can then be performed on the live drive in relative safety.

The key factor here is that you are working with production data, so extra care is the most important aspect.

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

[Robert_Boyd]

I second what Bob G just had to say about the physical backup. With the physical backup you have a copy of the data you can recover from file by file if necessary. Without the physical backup you could easily wind up without anything to go back to since it is unknown how far back this problem was introduced to the file system on the disk.
I.E. it could be very difficult to determine when the disk was last healthy enough to know that you got a successful "good" backup of the entire file system on the disk.

Robert

[LM_2]

Okay - I plan on coming in on Sunday - I will do a full backup - and then make sure that I can read the tape - then will go and rename the vicdataedi directory - then create a brand spankin' new directory called vicdataedi - create all new directories below it - and then copy the files from the old directories into their new ones. I am assuming that all my files are okay. Does this sound like a good plan??

[Robert Gezelter]

Lisa,

I disagree. This is production data. The BACKUP that you need is a PHYSICAL backup (ignoring the file system, that is what has been compromised).

Once there is a copy of the disk volume, the analysis of what is actually wrong can be done. I WOULD NOT RECOMMEND just starting to rename files and copying things without the analysis. You can end up making negative progress.

If the system is quiescent when you create the BACKUP (and copy it to spare disk space), you can then possibly skip the second set of BACKUPs, but I do recommend extra BACKUPs. As you mentioned this is production data. Media (and disk drives for that matter) are relatively inexpensive.

My concern is that we really at this point do not understand what happened, and what the state of the structure is. We (all of us) have been working on certain presumptions. If these presumptions are right, all the better. If they are wrong, that can be trouble (Ask any surgeon how often major surgery doesn't go according to plan).

My apologies in advance if the above seems dogmatic. I have done far too many salvage operations after attempted repairs to recommend anything other than caustious approaches to volume repair.

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

[Hein van den Heuvel]

Backup? Yes, great!

Copying file? No!

Hopefully not sounding disrespectfull, but suggesting to copy files aorund, after all this discoussion, suggests to me that you 'did not get it'.

Please be attempt to engage someone who has more experience in this area and/or re-read replies carefully. HP support? Some consulting outfit?

Good luck!
Hein.

[LM_2]

A little disrespectful - but oh well, I did get it - I was trying to keep it short - I meant by copying files from syslost into the new directories.

[LM_2]

_

[Hein van den Heuvel]

Ah, in your summary the anal/disk --> syslost was not explicitly mentioned, which confused me.

>> copying files from syslost into the new directories

Don't copy. The data is fine, it is (still) on the right disk, but in the wrong (syslost) directory. Just RENAME

Hein.

[Robert Gezelter]

Lisa,

I hope that I have been helpful, but I must echo Hein's overnight comments.

Having done this sort of thing many times, I must agree with his sentiments. I have spent far TOO MANY CLIENT dollars fixing mis-fired attempts to correct things. The differences between a trivial problem (a professor of mine one banned the word "trivial") and a serious problem is far too often only recognized in hindsight, after things have gone awry.

As I mentioned earlier, we have assisted clients with this type of problem in the past.

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

[LM_2]

No problem. I understand the complexity of this situation - yesterday was just a long day for me and I typed up my one reply rather quickly and didn't really read what I wrote. But, just to show I know what I am doing, I did backup the drive and copied it over to a test machine - I did the set file/nodir - deleted the directory - ran the analyze - renamed syslost - and everything worked fine. So I will be doing this entire process on Sunday in my production environment - so everything should be fine. Thanks for all your help on this.

[Robert Gezelter]

Lisa,

No problem. Your welcome.

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

[Steven Schweda]

Whose welcome? Or did you mean, "You're
welcome", as in "You are welcome"?

Or did I mean "Who's welcome"?

Try Google on "truss panda shoots". Then read
the book.

[Robert Gezelter]

Steve,

You are correct. I mistyped. It was meant as "You're welcome!".

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

P.S. I believe that the book you were referring to is "Eats shoots and leaves". For those who haven't seen the book, it is entertaining (the key to the title is that the meaning changes depending upon the punctuation).

[LM_2]

Thought I would let you all know - it worked like a charm and I had no problems!! Thanks again for everyone's responses.