Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

What's up with TSAFS

Status
Not open for further replies.
Joined
Jun 25, 2003
Messages
2,949
Location
US
Just wondering what other people are doing with TSAFS on NW6.5 and what kinds of problems are you having, and what you're doing to resolve.

I have one client that has 6 NetWare 6.5 servers. All are fine except for one. We've gone back and forth with TSA600 and TSAFS, from NW6.5 Original release to NW6.5 SP2 and still have crashes on SMDR and TSAxx when running backups. We're running BackupExec Remote Agent v9.1. I've also had problems with other clients and servers.. this is just an example.

The consensus seems to be that using TSA600 is the answer, but I have still had problems with TSA600, and Novell won't support it.

Thanks.

Marvin Huffaker MCNE, CNE
Marvin Huffaker Consulting
 
what kind of probs are you having

i'm using tsafs on all servers now , most with be 9.1 and no probs
 
Well, the biggest problem is that I seem to have lots of server abends while doing backups. Not just one server.. different servers, different companies, completely different environments.. And it doesn't abend it every time, it seems to abend at random.

I just installed NS65SP2 and the latest BE9.1 patch, plus I added a startup switch to TSAFS to prevent it from using so much memory.. So I'll have to see how it goes from here. None of the prior patches have fixed it.

Marvin Huffaker MCNE, CNE
Marvin Huffaker Consulting
 
must confess - although most of our are sp2 ,
a few still sp1 - i'm not getting any probs

i have no patches at all on BE, just vanilla

all our are hp's and all using support pack 7
 
FWIW Marvin -
We've been going through the same thing. (3 node NW 6.5 Sp1.1 cluster, 2 node cluster (same) all on fiber channel SAN) I have a hard time keeping the cluster running more than 2-3 weeks before mem fragmentation either takes it down or just plain stops the backup due to mem alloc failures. We're not on SP2 yet but did go on the TSA5UP15 patch. Also did TCPIP patches & CLib patch. Debating backreving to TSA600 until this is really resolved (this does work although it is not supported) I have an interim TSAFS version that IME ran better for us than the 5UP15 version, although still had issues. BTW - in SP2 look out for the memory leak in the DS & DSloader NLM's (already a hot fix out for that, or you can back rev the files to SP1.1)
TSAFS backup speeds have been great on the SAN, using Syncsort BEX 2.1.5D for LAN free backups. If they could just nail the TSAFS life would be perfect. We're running between 25 and 45 MB/sec (depending on file size basically).
 
Hey I just wanted to report back so others looking for solutions will have some hope.

I patched a problem NW6.5 server with NW65SP2 and the BackupExec 9.1 latest patch about 20 days ago. The server has been running rock solid ever since. (It was abending nightly before). Plus it doesn't leak memory any more either.


Marvin Huffaker MCNE, CNE
Marvin Huffaker Consulting
 
Marvin - have you put TSA5up16 in anywhere or tried the new Groupwise functionality? I'm eager to test it, but things have been running pretty well here so it's a 'sleeping dogs' kinda scenario. ;)
 
I've used various tsa5up patches over the last few months but they were for specific issues that I can't remember right now. Haven't tried the groupwise functionality yet.

The biggest problem I've been running into lately with NW6.5SP2 + edir 8.7.3.3 is a mem leak that still hasn't been identified by Novell.. And it's a very tempermental leak - might go for a couple months before leaking, then all of a sudden the cache memory drains completely. crazy. If you run into this, let me know and I can save you some headaches.

Marvin Huffaker MCNE, CNE
Marvin Huffaker Consulting
 
Yes. Basically I opened an Incident with Novell. And now we're going through TID 10091980 step by step. Here's what you do -- Go through it step by step.. Make the first recommended change.. wait to see if the leak comes back. If so, then go to the next one. The one thing that has seemed to help the most in the cases I've seen was hardcoding the amount of RAM used by Directory Services.





Marvin Huffaker MCNE, CNE
Marvin Huffaker Consulting, Inc.
 
hardcoding the amount of RAM used by Directory Services"

Interesting.

Wouldnt think those were related...



George Walkey
Senior Geek in charge
 
update: we're running GW backup with TSAFS from 5up17. Runs fine, have not had any abends in months. Groupwise functionality is good (gets all files) but I have a case open with Novell bc timestamping appears to be broken. As we have retention/compliance regs, no one can delete until the mail is time stamped.. and if time stamps don't happen no one can delete mail ever. Kinda bad.. so every morning I go to the console and run GWTMSTMP for whatever time the backup completed the night before. You wonder how these things get through QA, and why it takes tech support 2 weeks to get you a 1 minute answer.
Color me frustrated.
 
We did get to the bottom of the time stamp issue.. and there's even a TID about it now. ;) Trouble is something in TSAFS. If you run GW in protected memory (as we do) there is no GWENN4.NLM in OS memory space. TSAFS needs GWENN4 to perform the timestamping operation. Nevermind GWENN4 has to be in the path as TSAFS tries to blind load it.. something there is not working right. (I mean it should be able to load it without my assistance..) SO, I added a "load GWENN4.NLM" in my PO cluster resource load script. Now everyone is happy.
Backup is still just a few hairs faster than GWTSA, was hoping for more juice.. but at least clustering is not a problem anymore.
 
I was going to make some wisecracky comment about looking it up yerownself, but I could not get it to come up an any of my searches.. ithink their indexes are blown back in provo. I had to go into my browser history to find it myself! Ack! I applologize for my malicious thoughts at any rate. ;)

Seek you TID # 10096757

I especially enjoy the "this *may* be fixed in the next version.." I guess there is a 50% chance then. ;)
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top