ADSM-L

Re: Aggregates and transactions

2001-08-29 14:08:05
Subject: Re: Aggregates and transactions
From: Richard Sims <rbs AT BU DOT EDU>
Date: Wed, 29 Aug 2001 14:08:53 -0400
>Does TSM use batched aggregrates or some such when making copypool copies?

Tab - Your question reinforces the need for a TSM Performance manual or
      redbook.  The customer base is disappointed that we're into the fourth
incarnation of TSM and still there is no substantive performance guidance.

>Specifically, I have "MoveSizeThresh" set to 200 MB on my TSM server.  When
>I backup the primary storage pools to the copypool, is the data sent in 200
>MB chunks (subject to override by "TxnGroupMax")?

Server data is moved in transaction units whose capacity is controlled by the
MOVEBatchsize and MOVESizethresh server options.  MOVEBatchsize specifies the
number of files that are to be moved within the same server transaction, and
MOVESizethresh specifies, in megabytes, the amount of data to be moved within
the same server transaction. When either threshold is reached, a new transaction
is started.  The TxnGroupMax option does not really pertain here as you are
talking about in-server admin functions: TxnGroupMax is a client-server
transaction thing that does not pertain to servers per se unless you are talking
server-to-server operations.

>I ask because in the course of troubleshooting our HP DLT library, the HP
>tech said that modern drives are so fast that older servers - like my F50 -
>can't keep up, and that causes what HP calls "shoe-shining" of the drives.
>The frequent stop/start cycles burn up the drives and they say they're
>seeing it in their LTO drives as well.

I have 3590 drives, and I have to shine my shoes myself.  :-(
The HP technician's insights are valuable unto themselves; but other hardware
choices, load balancing, performance tuning, device drivers, microcode, and like
factors all affect the data rate to the drive.  The SCSI adapter type and number
of drives on the SCSI chain, for example, is a factor.  Regardless of any of the
factors outside the tape drive, the drive itself must accommodate real-world
needs, and skip-around processing during restorals in particular is something we
need a tape drive to do: all uses cannot  be streaming.  I'm not a DLT
customer, but gauging from some of the DLT postings, I think a lot of those
customers are amused at the proposition of DLT being faster than the host.
In any case, all technology must be chosen according to dominant needs being
met by device performance characteristics.

I'd like to hear from customers who have been DLT users and who have gone on to
Super DLT, to see how that stacks up in real conditions.

  Richard Sims, BU
<Prev in Thread] Current Thread [Next in Thread>