Author: Henk ten Have <hthta AT NCSA.UIUC DOT EDU>
Date: Fri, 1 Apr 2005 07:29:21 -0600
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 b
Author: Zoltan Forray/AC/VCU <zforray AT VCU DOT EDU>
Date: Fri, 1 Apr 2005 11:03:12 -0500
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 fa
Ya, Sorry, I have no answers for you, but you do have my sympathy. I've had to do that kind of detective work before. Some times it is an oddly named file, a very very long-named file, or some times
Author: Zoltan Forray/AC/VCU <zforray AT VCU DOT EDU>
Date: Mon, 28 Mar 2005 17:22:05 -0500
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 su
Author: "Mark D. Rodriguez" <mark AT MDRCONSULT DOT COM>
Date: Mon, 28 Mar 2005 16:30:23 -0600
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
Author: "Meadows, Andrew" <AMeadows AT BMI DOT COM>
Date: Mon, 28 Mar 2005 16:46:42 -0600
I would also definitely suggest Journaling after the first incremental backup completes, that would help negate the slower backups with memory efficient turned on. Zoltan, I am not sure if this will
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
Author: "Mark D. Rodriguez" <mark AT MDRCONSULT DOT COM>
Date: Mon, 28 Mar 2005 17:17:56 -0600
Andrew, This is a Linux client. I do not believe that journal backups are supported under Linux. As far as I know it is a windows only thing or at least thats what all the documentation says anyway.
Author: Zoltan Forray/AC/VCU <zforray AT VCU DOT EDU>
Date: Tue, 29 Mar 2005 08:26:25 -0500
Thanks for the suggestion. We have tried it. Same results. Things just go to sleep ! "Mark D. Rodriguez" <mark AT MDRCONSULT DOT COM> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
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 bi
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 r
Author: Andrew Raibeck <storman AT US.IBM DOT COM>
Date: Tue, 29 Mar 2005 10:07:17 -0700
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 SES
Author: Zoltan Forray/AC/VCU <zforray AT VCU DOT EDU>
Date: Tue, 29 Mar 2005 12:37:40 -0500
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 accumulatio
Author: Zoltan Forray/AC/VCU <zforray AT VCU DOT EDU>
Date: Tue, 29 Mar 2005 12:59:20 -0500
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: "linux8
...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".
Author: Zoltan Forray/AC/VCU <zforray AT VCU DOT EDU>
Date: Tue, 29 Mar 2005 13:39:46 -0500
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,
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 Beo
Author: Zoltan Forray/AC/VCU <zforray AT VCU DOT EDU>
Date: Tue, 29 Mar 2005 14:16:59 -0500
Did a ulimit -s unlimited. Dies the same way when trying to backup the /coyote/dsk3/ fs - Producer Thread........ Richard Sims <rbs AT BU DOT EDU> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MAR
Author: "Stapleton, Mark" <mark.stapleton AT BERBEE DOT COM>
Date: Tue, 29 Mar 2005 13:24:56 -0600
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 Beowulf cluster you running) breaks somet