Environment
Novell NetWare 6.5 Support Pack
6
Novell NetWare 6.5 Support Pack 5
IBM Tivoli TSM Client v5.3.0.12
IBM Tivoli TSM Client v5.3.4.0
Novell NetWare 6.5 Support Pack 5
IBM Tivoli TSM Client v5.3.0.12
IBM Tivoli TSM Client v5.3.4.0
Situation
Symptoms
Customers running NetWare may encounter a severe backup performance degradation (between 3x - 7x !!) after upgrading the IBM Tivoli TSM Client v5.3.0.12 to, in this case, the v5.3.4.0 version, that was needed for it's UTF8 support.
Customers running NetWare may encounter a severe backup performance degradation (between 3x - 7x !!) after upgrading the IBM Tivoli TSM Client v5.3.0.12 to, in this case, the v5.3.4.0 version, that was needed for it's UTF8 support.
Resolution
Workaround(s)
used
- One workaround we used was to install one of the clients into a separate directory, and use when needed
- Unload any virus scanner from the server the TSM client is running
Corrective Steps:
Starting with Novell NetWare Support Pack 7 two modules have been modified to overcome the above described problem by making additional changes in LIBC and COMN.NSS which precludes calls to FSHooks (including NEB) when open/create is called with no read or write access is requested.
- One workaround we used was to install one of the clients into a separate directory, and use when needed
- Unload any virus scanner from the server the TSM client is running
Corrective Steps:
Starting with Novell NetWare Support Pack 7 two modules have been modified to overcome the above described problem by making additional changes in LIBC and COMN.NSS which precludes calls to FSHooks (including NEB) when open/create is called with no read or write access is requested.
Status
Top IssueAdditional Information
Notes
The problem ha been identified as to where Tivoli's TSM client has so far been using the 'older' Clib ScanTrustees API, whereas the new client is using the recent LibC's nxScanTrustees & zOpen API to scan for trustee information.
Further profiling a server through Netware Remote Manager, it turns out that a zOpen took about 130 microsec, and a COMN lookup accounts for about 10 of that. Further digging revealed that FH_HOOKS (from a running virusscanner) took about 115 microsec's average per lookup. After unloading the virus scanner the zOpen calls dropped to 13 microsec on average which is approx. a 10x speed increase
The problem ha been identified as to where Tivoli's TSM client has so far been using the 'older' Clib ScanTrustees API, whereas the new client is using the recent LibC's nxScanTrustees & zOpen API to scan for trustee information.
Further profiling a server through Netware Remote Manager, it turns out that a zOpen took about 130 microsec, and a COMN lookup accounts for about 10 of that. Further digging revealed that FH_HOOKS (from a running virusscanner) took about 115 microsec's average per lookup. After unloading the virus scanner the zOpen calls dropped to 13 microsec on average which is approx. a 10x speed increase
Change Log
7 Jun 2013 - Removed 'Reported to Engineering' status.