We have a TSM server that handles VMs exclusively. There is the TSM server, TSM1, and another server for 15 Datamovers, LIN3.
Everything has been stable for some time, but starting last week, quiescing errors (115) have started to fill up the error log of different data movers at an alarming rate. Yesterday evening, during backups, it got stuck on db169/disk 4 and filled up over 200GB. (other times the problem server was different as well as the datamover) I wound up having to delete the error log after copying a portion of it. Eventually I had to reboot the datamover box to make the memory available to the OS.
My co-worker tried adding the ERRORLOGMAX statement to the dsm.sys file for the datamover that was acting up. (I don't have write rights to that particular server) She told me it returned an error and wouldn't accept it.
The first time this happened I put in a call to IBM, and I got an e-mail from a first level fellow who requested an INSANE amount of traces, config files, etc. much of which was clearly irrelevant.
We are on TSM 7.1.1 on Red Hat Linux Enterprise 6.7.
Following is the repeated snippet in the error log from LIN3 (datamover 0, file name dsmerror0.log)(server names changed for clarity):
TSM return code : 115
TSM file : vmbackvcm.cpp (218)
10/05/2015 22:23:29 ANS5250E An unexpected error was encountered.
TSM function name : vcmLogger::trace
TSM function : CacheManager::swap_out: Can't write object (id='Path: '/tmp/tsmvmbackup/fullvm/CDF_Local/DB169/Hard Disk 4' Job: 43004 MB Number: 1431')
TSM return code : 115
TSM file : vmbackvcm.cpp (218)
10/05/2015 22:23:29 ANS5250E An unexpected error was encountered.
TSM function name : vcmLogger::trace
TSM function : CacheManager::swap_out: Can't write object (id='Path: '/tmp/tsmvmbackup/fullvm/CDF_Local/DB169/Hard Disk 4' Job: 43004 MB Number: 1432')
Everything has been stable for some time, but starting last week, quiescing errors (115) have started to fill up the error log of different data movers at an alarming rate. Yesterday evening, during backups, it got stuck on db169/disk 4 and filled up over 200GB. (other times the problem server was different as well as the datamover) I wound up having to delete the error log after copying a portion of it. Eventually I had to reboot the datamover box to make the memory available to the OS.
My co-worker tried adding the ERRORLOGMAX statement to the dsm.sys file for the datamover that was acting up. (I don't have write rights to that particular server) She told me it returned an error and wouldn't accept it.
The first time this happened I put in a call to IBM, and I got an e-mail from a first level fellow who requested an INSANE amount of traces, config files, etc. much of which was clearly irrelevant.
We are on TSM 7.1.1 on Red Hat Linux Enterprise 6.7.
Following is the repeated snippet in the error log from LIN3 (datamover 0, file name dsmerror0.log)(server names changed for clarity):
TSM return code : 115
TSM file : vmbackvcm.cpp (218)
10/05/2015 22:23:29 ANS5250E An unexpected error was encountered.
TSM function name : vcmLogger::trace
TSM function : CacheManager::swap_out: Can't write object (id='Path: '/tmp/tsmvmbackup/fullvm/CDF_Local/DB169/Hard Disk 4' Job: 43004 MB Number: 1431')
TSM return code : 115
TSM file : vmbackvcm.cpp (218)
10/05/2015 22:23:29 ANS5250E An unexpected error was encountered.
TSM function name : vcmLogger::trace
TSM function : CacheManager::swap_out: Can't write object (id='Path: '/tmp/tsmvmbackup/fullvm/CDF_Local/DB169/Hard Disk 4' Job: 43004 MB Number: 1432')