ssage.
Luckily I only have to do it about once or twice a year, but it
is time consuming.
Ben
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Zoltan Forray/AC/VCU
Sent: Friday, April 01, 2005 9:03 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: La
Thanks for the suggestion. However, this is not true. We already tried
this.
We did "find . | wc -l" to get the object count (1.1M) with no problems.
But the backup still will not work. Constantly fails, in
unpredictable/inconsistant places, with the same "Producer Thread" error.
I spent 2+ da
An old trick I used for many years:
to investigate a "problem" filesystem, do a "find" in that filesystem.
If the find dies, tsm definitly will die.
I'll bet your find will die, and that's why your backup will die/hang or
whatever also. A find will do a filestat on all files/dirs, actually the sa
>On Mar 29, 2005, at 1:39 PM, Zoltan Forray/AC/VCU wrote:
>> FWIW, this is RH8 as a Beowulf cluster, so NO, I can not upgrade the
>> OS.
Well, to be frank about it, you're using an unsupported version of
Linux.
That's a bit of a cop-out, I fear, but there may well be reasons that
RH8 (and the Beo
Did a ulimit -s unlimited.
Dies the same way when trying to backup the /coyote/dsk3/ fs - Producer
Thread
Richard Sims <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager"
03/29/2005 01:53 PM
Please respond to
"ADSM: Dist Stor Manager"
To
ADSM-L@VM.MARIST.EDU
cc
Subject
Re: [ADS
On Mar 29, 2005, at 1:39 PM, Zoltan Forray/AC/VCU wrote:
Here ya go. Pretty much no limits. I am open to suggestions on values
to
change that might help !
I did recommend addressing the Stacksize to try to head off the
defect...
FWIW, this is RH8 as a Beowulf cluster, so NO, I can not upgrade the
O
Here ya go. Pretty much no limits. I am open to suggestions on values to
change that might help !
FWIW, this is RH8 as a Beowulf cluster, so NO, I can not upgrade the OS.
Also, while on the subject, I read the "requirements" on the 5.3.x client,
that says it has only been tested on RH AS 3. Anyon
On Mar 29, 2005, at 12:37 PM, Zoltan Forray/AC/VCU wrote:
...However, then I try to backup the tree at the third-level (e.g.
/coyote/dsk3/), the client pretty much siezes immediately and
dsmerror.log
says "B/A Txn Producer Thread, fatal error, Signal 11". The server
shows
the session as "SendW" an
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 applicab
I am going down this path, already. I have started doing some instrument
traces. However, the results seem to show nothing, when backing up only
specific sub-sub-subdirectories. What time accumulation there is, is in
"Solve Tree" and/or "Process Dirs". No big surprise, there.
However, then I try
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
Zoltan Forray/AC/VCU wrote:
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 rela
Zoltan,
I had a similar problem on a Windows box with 5.4 million files. Tivoli
said that I couldn't do the backup/restore with a 32 bit client because
each file in the catalog takes 1k and the 32 bit program could only
address 4 GB of memory. Here is a link they gave me:
http://www-1.ibm.c
Thanks for the suggestion.
We have tried it. Same results. Things just go to sleep !
"Mark D. Rodriguez" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager"
03/28/2005 05:30 PM
Please respond to
"ADSM: Dist Stor Manager"
To
ADSM-L@VM.MARIST.EDU
cc
Subject
Re: [ADSM-L] Large Linux c
on.
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Mark D. Rodriguez
Sent: Monday, March 28, 2005 4:30 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Large Linux clients
Zoltan,
I am not sure if this will fix the problem or not. I have seen in the
past
Some things to consider with large file systems, and Unix ones in
particular:
1. Use CLI type backups rather than GUI type, for speed.
2. "Divide and conquer": Very large file systems are conspicuous
candidates for Virtualmountpoint TSM subdivision, which will greatly
improve things overall. For th
, March 28, 2005 4:30 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Large Linux clients
Zoltan,
I am not sure if this will fix the problem or not. I have seen in the
past when trying to backup directories (including sub-directories) with
a large number of files that the system runs out of memory and either
Zoltan,
I am not sure if this will fix the problem or not. I have seen in the
past when trying to backup directories (including sub-directories) with
a large number of files that the system runs out of memory and either
fails or hangs for ever. The one thing that I have done and has worked
in som
18 matches
Mail list logo
