Bad candidatesPool File Entry

[tcarroll]

We have a bad entry in one of our candidates pool files. Does anyone know the best/safest way to remove the entry?

We have fixed the file and directory that caused the bad entry, but HSM is not self repairing and the dsmerror.log file filles the filesystem in about 6 minutes.



Skipping invalid line found in candidate file /etc/adsm/SpaceMan/candidatesPool/APool.xxx.xxx



Thanks,

Tom

 

[PJ]

I'm sure we had that very same problem - but I can't find any record about it in our support DB. I think what we had to do was to empty the pool (copy /dev/null over it) - but I'm not sure. So unless you've got nothing to loose anyway, you might want to call suport for this.



Cheers

PJ

 

[tcarroll]

Thanks PJ,



I don't think we need to go to that extreme since I can see the line that is bad. But, the PMR has been open with Tivoli for over 24 hours with no answer to the question and I was hoping someone else had seen this.



If IBM doesn't get back to me in a couple more hours, I'm probably going to try deleting the entry and see what happens.

 

[PJ]

Theoretically the scoutdaemon should just start refilling the pools. Getting support for something like this at this time of day might be difficult. HSM development is here in Germany, and its friday night, 9:40 PM. My experience with HSM so far is, that the usual 1st and 2nd level support lines know little to nothing about the product. Too exotic



Cheers

PJ

 

[tcarroll]

Just to wrap this topic up.



What we did was:

1) dsmq #Check for any recall requests

2) dsmmigfs deactivate /filesystem/in/question

3) kill -15 on any running automigrate processes for the specific filesystem.

4) kill -15 on the dsmscoutd process.

5) remove offending entries from the candidates pool file.

6) restart dsmscoutd.

7) dsmmigfs reactivate /filesystem/in/question.



About 5 minute down time for filesystem migrates and recalls.