TSM Linux client: fsCheckAdd: unable to update filespace on server

[pichelman]

Hi,

I have getting these lines in my dsmerror.log while backing up "incrementally" every night with one of my TSM Linux nodes/clients:

##################################################

Errors:
-------

04/14/2008 21:09:07 ANS1898I ***** Processed 88,000 files *****
04/14/2008 22:31:20 ANS1228E Sending of object '/data' failed
04/14/2008 22:31:20 ANS1301E Server detected system error


04/14/2008 22:31:20 fsCheckAdd: unable to update filespace on server
04/14/2008 22:31:20 ANS1228E Sending of object '/data' failed
04/14/2008 22:31:20 ANS1301E Server detected system error

04/14/2008 22:31:21 ANS1809W Session is lost; initializing session reopen procedure.
04/14/2008 22:31:21 ANS1809W Session is lost; initializing session reopen procedure.
04/14/2008 23:04:02 ANS1512E Scheduled event 'ATHENA_INCR' failed. Return code = 12.


I search for some clues and found these Explanations:
----------------------------------------------------

If accompanied by "fsCheckAdd: unable to update Filespace on Server" in the ErrorLog, it may be that Database locks were

in effect, as when a serious operation like ExportNode is happening the same time as a Backup. Be careful to not have

conflicting things running. With .NET, note that *.cch.* Files are temporaries: consider excluding them from backup.


This is an obscure error, so you won't get many responses.
I would inspect the Activity Log for that time period to look for
some indication of the problem there. Beyond that, perform
Query Filespace for that node and look for something suspicious
with that file system name, and in the same theme check the client
for any odd specs it may have influencing the processing of that
file system (especially any Virtualmountpoint specs).
If nothing turns up, start experimenting to probe the problem, as
in doing 'dsmc archive /main/something' and/or
'dsmc selective /main/something' to see what works, what doesn't,
and what results on the server.

################################################


This error does "not" appear to happen when I run Archive backups for the same client?

I check the filespace and queried occupancy and I am not sure what is happening?
I even backup NFS mounts and they appear to be backing up - not my JFS filesystem called "/data"?

--> q filespace and q occ below:

ATHENA /data 7 Linux86 EXT3 No 705,363. 92.7 04/11/2008 4 04/12/2008 3 1 21:00:41 02:51:42


ATHENA Bkup /data 7 DISKPOOL2 89,089 28,074.67 26,243.39
ATHENA Bkup /data 7 LTOPOOL1 3,161,017 1,018,801 973,115.3
.49 5
ATHENA Bkup /data 7 LTOPOOL2 25,283 6,612.14 5,591.09


COPuldI have a uinicode issue?
I didn;t rename my filespace?
Although there is an NFS mount I don't backup anymore...

ATHENA /LACIE 12 Linux86 UNKNOWN No 1,903,74 12.2 06/16/2007 304
4.0 08:44:46

################################################## ###
These lines below in the dsm.opt file for backing by filespace seem to have always worked?

DSM.OPT:
---------

SErvername server1
COMPRESSALWAYS No
domain /MSNWEB
domain /data
domain /usr/local

DSM.SYS:
---------

SErvername server1
NODename ATHENA
COMMmethod TCPip
TCPPort 1500
TCPServeraddress 192.168.1.5
*TCPServeraddress 10.97.20.5
*TestFlag instrument:detail
TxnByteLimit 25600
ResourceUtilization 1
*ResourceUtilization 5
*DISKBUFFSIZE 32
*TCPBuffsize 32
TCPBuffsize 64
TCPWindowsize 64
LargeCommBuffers No
MemoryEfficientBackup No
TCPNoDelay Yes
USERs root
COMPRESSIon No
*Preschedulecmd "/usr/local/scripts/pre_sched_msnweb_mount.sh"
*Preschedulecmd "/usr/local/scripts/reset_migr_dskpl.sh"
PostScheduleCmd "/usr/local/scripts/drm.sh"
CHAngingretries 2
PASSWORDAccess generate
MAILprog /bin/mail scott.pichelman@weirminerals.com
SCHEDMODe Polling
SCHEDLOGRetention 14,D
ERRORLOGRetention 14,D
SCHEDLOGName "/var/log/dsm/dsmsched.log"
ERRORLOGname "/var/log/dsm/dsmerror.log"
INCLExcl /etc/dsm-inclexcl

Don't suppose my "dsm-inclexcl" file makes a difference...
Could there be an issue with the TSM DB being corrupted or out of whack?
Sorry for so much info to digest - anyone have any ideas?
Thanks.

P

[cheffern]

hi -

I don't know if anyone else ever ran into this or fixed it -
but I got around it by using a new nodename on the TSM server for the particular client.
however, going back for recovery may be an issue...not and won't be sure until I hit that bridge...

-Chef.