Hi Michael, we experienced the same thing when we asked clients to upgrade to 5.4.1.2 ( to avoid the security vulnerability in the dsmcad ): Incrementals started backing up the entire filestore - which gave us a headache at the server end. Running: dsmc incr -traceflags=service -tracefile=/path/to/file on the client showed that it was ACL-related extended attributes that were causing files to be sent again to the server ( see trace output below my signature ): essentially, the client sees the file ACL attributes as 'changed' ( because it has, as yet, no ACL attribute data on the server ) and instead of updating the file attributes at the server end, it sends the whole file again.
try searching for the string ATTRIBS_BACKUP and ATTRIBS_EQUAL in the output tracefile. IBM support state that ACL support was introduced in 5.3, but we're pretty sure that we saw this behaviour even in clients moving from 5.3.x to 5.4.x. allthough we didn't pursue this. If this is your experience, you can bypass this with the 'SKIPACL' and 'SKIPACLUPDATECHECK' options __but__ our experience has shown that this dramatically slows the incremental processing on the client. At the very least, take a look at the manual on these options, and test them if unsure. HTH Ian Smith Oxford University Computing Services. UK -- Begin trace file excerpt -- 06-11-2007 12:08:02.353 [016096] [4144462752] : incrdrv.cpp (14330): Incremental attrib compare for: /blah/man/man1/vacuumdb.1 06-11-2007 12:08:02.353 [016096] [4144462752] : unxfilio.cpp (1556): fioCmpAttribs: skipACL:'0', skipACLUpdateCheck :'0' 06-11-2007 12:08:02.353 [016096] [4144462752] : unxfilio.cpp (1673): fioCmpAttribs: Attribute comparison of two fil es Attribute Old New --------- --- --- ctime 1191576650 1191576650 mtime 1187781793 1187781793 atime 1191576650 1192659176 File mode OCT 100644 100644 uid 0 0 gid 0 0 size 4172 4172 ACL size 0 0 ACL checksum 0 0 Xattr size 54 Xattr checksum 0 1188981555 inode 91373877 91373877 06-11-2007 12:08:02.353 [016096] [4144462752] : fileio.cpp (4627): fioCmpAttribs(): old attrib's data from build (IBM TSM 5.4.1.2) 06-11-2007 12:08:02.353 [016096] [4144462752] : unxfilio.cpp (1765): -->ACL different: returning ATTRIBS_BACKUP ========================================== -- End trace file excerpt -- On Tuesday 11 Dec 2007 8:03 pm, Michael Glad wrote: > I run a TSM 5.3.4.0 TSM server. I recently encounterered a problem where > the 5.3.4.0 linux TSM client aborted every time it processed a given file > system on one of my servers. > > Instead of upgrading to a newer 5.3.4 client level as would probably have > been the wisest thing to to, I promptly uninstalled it and installed > a 5.4.1.5 client. > > Unfortunately, it seems that the 5.4.1.5 client wants to back up a lot of > files that have already been backed up, possibly the entire server. > As this server contains a 8 digit number of files, this is far from > ideal. > > Does somebody have an idea of what's going on? > > -- Michael