Some more details.

I added the TRACE???? options you recommended.

While the backup still immediately fails, I got some more information.

The "Producer Thread" failure now includes the detail:
"linux86/psunxthr.cpp (184)".   The only hit I get on these messages, is
apar: IC30292. But the applicable components listed says:  R42L PSY, which
I read as 4.2 ?   This client is 5.2.3.0 !




Andrew Raibeck <storman AT US.IBM DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
03/29/2005 12:07 PM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
Re: [ADSM-L] Large Linux clients






First, you should work with whoever owns that system in order to ensure
that you can get the access you need to perform your investigations.

When the backup appears to "hang", what does the QUERY SESSION admin
command show for this node?

Is the TSM process consuming any CPU?

Configure the client for a SERVICE trace by adding the following to
dsm.opt:

   TRACEFILE tsmtrace.txt
   TRACEFLAGS SERVICE
   TRACEMAX 20

(for TRACEFILE, specify whatever directory and file name you want, enough
to store a 20 MB file.)

Then use the command line client (dsmc) to run an incremental backup
against the problem file system and wait for the problem to reoccur. Check
the QUERY SESSION output and CPU utilization for dsmc, as I mentioned
above.

You can view the trace file with a text editor, and look for the line that
reads "END OF DATA" to see what the last thing the client was doing. Look
and see if you have any recursive directory structures. Open a problem
with IBM support and provide them with the results of the info I mentioned
above (let me know, too).

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 2005-03-28
15:22:05:

> I am having issues backing up a large Linux server (client=5.2.3.0).
>
> The TSM server is also on a RH Linux box (5.2.2.5).
>
> This system has over 4.6M objects.
>
> A standard incremental WILL NOT complete successfully. It usually
> hangs/times-out/etc.
>
> The troubles seem to be related to one particular directory with
> 40-subdirs, comprising 1.4M objects (from the box owner).
>
> If I point to this directory as a whole (via the web ba-client), and try
> to back it up in one shot, it displays the "inspecting objects" message
> and then never comes back.
>
> If I drill down further and select the subdirs in groups of 10, it seems
> to back them up, with no problem.
>
> So, one question I have is, anyone out there backing up large Linux
> systems, similar to this ?
>
> Any suggestions on what the problem could be.
>
> Currently, I do not have access to the error-log files since this is a
> protected/firewalled system and I don't have the id/pw.