ADSM-L

[ADSM-L] Performance tip for pre-5.3.5 clients

2008-02-06 10:56:50
Subject: [ADSM-L] Performance tip for pre-5.3.5 clients
From: Richard Sims <rbs AT BU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 6 Feb 2008 10:55:59 -0500
We do a lot of Unix mail (sendmail) spool file (Inbox) backups with
TSM 5.2 clients on AIX.  In the client backup log it was common to
see retries, as one would expect in busy file systems, particularly
with spam being delivered to these mbox format files.

Out of curiosity, I decided to analyze one of those backups as it was
running...  The TSM client reported that a file had Changed, then did
a Retry, so I performed an 'istat' command on the file - and was
surprised to see that the file's modification time was actually
considerably earlier than the time of the attempted backup.  That
doesn't make sense: retries should happen for files which TSM found
changed at the time of backup.  So what's going on?

Performing research in the IBM database, I discovered APAR IC48891.
It turns out that this behavior is the result of a surprisingly bad
design deficiency that has been in effect for quite some time.  The
TSM client would gather file attributes at the time it entered a
directory, not when it started work on a file, resulting in stale
attribute time values being used in determining whether to perform a
retry, and thus a lot of erroneous retries for files which had not
actually changed during the backup operation.

I decided to try the circumvention testflag noted in the APAR:
Whereas the nightly backups were loaded with retries, my test backup
with the testflag had very few retries, and those were proved valid
via 'istat'.  (The corresponding Linux command is 'stat'.)  The
reduction in backup time was *DRAMATIC*.  And, of course, both the
communication link and the TSM server are much less busy due to the
much reduced traffic.  (Keep in mind that a retry has to redo the
whole transaction's worth of files, not just one file!)

If you have clients older than 5.3.5, have a look at that APAR.  I
added that testflag to http://people.bu.edu/rbs/ADSM.QuickFacts, to
explain it as a customer perceives it (seek on ENABLEGETFILSIZE).
You can verify if your client supports the testflag by first
physically inspecting the dsmc module to see if that word is in
there, and by adding it to your option file and doing the usual 'dsmc
q opt' to verify acceptance.

    Richard Sims   at Boston University

<Prev in Thread] Current Thread [Next in Thread>
  • [ADSM-L] Performance tip for pre-5.3.5 clients, Richard Sims <=