Hi David,
Two factors that I've seen make a difference (and this was Windows
platform only, and may no longer apply) are the I/O size, and which of
storport/miniport drivers are in use.
Its anecdotal, but I've been told there is not much extra CPU to spare in
an LTO tape drive. The more small I/Os the tape drive does over fibre
channel, the more the throughput will be hurt.
Two different tape drives, on otherwise identical HBA can perform
differently if one of the HBA defaults to the windows driver and the other
gets a higher performing driver.
YMMV,
[RC]
From:
David Longo <David.Longo AT HEALTH-FIRST DOT ORG>
To:
ADSM-L AT VM.MARIST DOT EDU
Date:
05/05/2010 10:45 AM
Subject:
Re: [ADSM-L] Backing up Light Speed compressed files
Sent by:
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Several folks suggested not compressing on tape. As my LTO2 devclass was
format: ULTRIUM2C, I created another devclass that was just ULTRIUM2.
Then created new primary and copy tape pools and pointed to them.
(This one client was in a Domain by itself, so I had more freedom to do
this.)
Results were little different, still takes twice as long to backup (or
do tape to tape copy) of a 62 GB compressed file as same size uncompressed
file. Main thing I noticed, was that the few uncompressed files, some 5-7
GB I could see they took longer than on compressed tape, that seems
logical
and I think proves Andy's point here.
Now, maybe I had it wrong, I would have thought it took as
long to backup as certain size file whether compressed or not,
as long as you are not trying to compress it more?
So, I changed everything back to original devclass, etc.
Some folks at my site tried to discuss things to change on the client.
I told them if tape to tape is taking that long, no need to spend
time on the client side, it's just the way it is with these compressed
files.
I will say that this new method is better than before, we went from 11-12
hours
to backup this client with 1.2 TB of data to about 4 hours to backup 250
GB of data.
Most people would be delighted with that improvement! We just thought
we could get it down to 2 hours.
This also I think proves a suspicion I have had about a few other clients.
They have compressed files normally, many on the size of a few GB or more,
not as
big as current issue. Now, I realize they have the same problem, not as
fast, even
with tape to tape copy, as I would expect. Totally different application
and
compression of files on disk by the application. I believe they are
taking twice
as long as they should.
If anybody figures out how to speed up backing up files not compressed by
TSM, let me know!
Thanks,
David Longo
>>> "Huebner,Andy,FORT WORTH,IT" <Andy.Huebner AT ALCONLABS DOT COM> 4/28/2010
6:25 PM >>>
LTO2 writes to tape at maximum of 40MB/sec. If the data compresses 3.5:1
then your server will need to feed the tape drive at 140MB/sec to keep up
with the write speed. If the data compresses 1:1 then you only need to
send data at 40MB/sec.
This kind of thing used to drive me nuts until I figured out it takes
about 1 hour to fill one of my tapes, regardless of the amount of data
written. If it takes longer then there is a problem. In your case 85
minutes is the minimum, probably a little under 2 hours is a realistic
time.
Andy Huebner
"You have to think 4th dimensionally."
Emmitt L. Brown
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
David Longo
Sent: Tuesday, April 27, 2010 1:44 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Backing up Light Speed compressed files
I have never been concerned with compressed files, never used
compression on TSM - except on my LTO tapes.
Now, we have a new situation. We have had a client with SQL DB and
the DBA's do the dumps to disk and I pick up. (Can't use TDP SQL,
long story.) The dumps were lately (6) 200 GB files, total 1.2 TB and
growing daily. Took about 11 hours to backup directly to LTO2 tapes.
DBA's just implemented using Quest's Light Speed using their Level 4
compression - whatever that is. The dumps are now (4) 62 GB files,
so about a 5 to 1 compression.
The TSM backup took much less time, but not as much less as expected.
When the offsite copy was made, LTO2 to LTO2, I found out why.
For a certain file size, it takes twice as long to back it up for a
compressed file as an uncompressed file.
For more info, on the LTO2 tapes, before we would get just over 700 GB
on them, now just over 200 GB. (Using q vol stats). I kinew it would be
less obviously.
Anybody know why takes twice as long? Is there a way to speed it up?
Thanks,
David Longo
#####################################
This message is for the named person's use only. It may
contain private, proprietary, or legally privileged information.
No privilege is waived or lost by any mistransmission. If you
receive this message in error, please immediately delete it and
all copies of it from your system, destroy any hard copies of it,
and notify the sender. You must not, directly or indirectly, use,
disclose, distribute, print, or copy any part of this message if you
are not the intended recipient. Health First reserves the right to
monitor all e-mail communications through its networks. Any views
or opinions expressed in this message are solely those of the
individual sender, except (1) where the message states such views
or opinions are on behalf of a particular entity; and (2) the sender
is authorized by the entity to give such views or opinions.
#####################################
This e-mail (including any attachments) is confidential and may be legally
privileged. If you are not an intended recipient or an authorized
representative of an intended recipient, you are prohibited from using,
copying or distributing the information in this e-mail or its attachments.
If you have received this e-mail in error, please notify the sender
immediately by return e-mail and delete all copies of this message and any
attachments.
Thank you.
U.S. BANCORP made the following annotations
---------------------------------------------------------------------
Electronic Privacy Notice. This e-mail, and any attachments, contains
information that is, or may be, covered by electronic communications privacy
laws, and is also confidential and proprietary in nature. If you are not the
intended recipient, please be advised that you are legally prohibited from
retaining, using, copying, distributing, or otherwise disclosing this
information in any manner. Instead, please reply to the sender that you have
received this communication in error, and then immediately delete it. Thank you
in advance for your cooperation.
---------------------------------------------------------------------
|
