Neil,

Thanks for the info.  I have passed this on to my SAN guys since I know
nothing about this aspect of the configuration nor if we can make these
tweaks.

I am still wondering if I should go back to the traditional fixed size,
pre-formatted volumes.  Everyone says filedevclass is supposed to be
faster and better so I thought I would give it a try.
Zoltan Forray
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zforray AT vcu DOT edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://infosecurity.vcu.edu/phishing.html



From:
"Strand, Neil B." <NBStrand AT LEGGMASON DOT COM>
To:
ADSM-L AT VM.MARIST DOT EDU
Date:
10/19/2010 01:50 PM
Subject:
Re: [ADSM-L] Lousy performance on new 6.2.1.1 server with SAN/FILEDEVCLASS
storage
Sent by:
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>



Zoltan,
   You may need to increase the queue depth for the individual disks
and/or the HBA attached to the disks.
   Monitor both the server (iostat/vmstat) and the storage (EMC voodoo
application) for latency and compare the results for consistency.  You
may need to adjust the striping of your logical LUNs on the storage.  I
have observed serious performance degradation on an older IBM ESS simply
because the logical volumes were created on a single SSA rather than
spread across the entire set of disks.

Cheers,
Neil Strand
Storage Engineer - Legg Mason
Baltimore, MD.
(410) 580-7491
Whatever you can do or believe you can, begin it.
Boldness has genius, power and magic.


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Zoltan Forray/AC/VCU
Sent: Tuesday, October 19, 2010 9:15 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Lousy performance on new 6.2.1.1 server with
SAN/FILEDEVCLASS storage

Now that I have ventured into new territory with this new server (Linux
6.2.1.1), I am experiencing terrible performance when it comes to moving
data from disk (FILEDEVCLASS on EMC/SAN storage) vs my other 6.1 and 5.5
servers.

With the server doing nothing but migrating data from this SAN based
stgpool to TS1130 tape, I am seeing roughly 700GB being moved in a
12-hour
period.  On my other, internal disk based TSM servers, I move
multiple-terabytes per day/24-hours.

So, where should I focus on why this is so slow?  Is it because I am
using
SAN storage?  How about the FILEDEVCLASS vs fixed, pre-formatted volumes
(like every other server is using)?

Or is this normal?  If it is, I am in for some serious problems.  One of
these servers is expected to replace an existing 5.5 server that
processes
20TB+ of backups, per week (no, I can not go straight to tape due to the
type of backups being performed).

Suggestions?  Thoughts?
Zoltan Forray
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zforray AT vcu DOT edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://infosecurity.vcu.edu/phishing.html

IMPORTANT:  E-mail sent through the Internet is not secure. Legg Mason
therefore recommends that you do not send any confidential or sensitive
information to us via electronic mail, including social security numbers,
account numbers, or personal identification numbers. Delivery, and or
timely delivery of Internet mail is not guaranteed. Legg Mason therefore
recommends that you do not send time sensitive
or action-oriented messages to us via electronic mail.

This message is intended for the addressee only and may contain privileged
or confidential information. Unless you are the intended recipient, you
may not use, copy or disclose to anyone any information contained in this
message. If you have received this message in error, please notify the
author by replying to this message and then kindly delete the message.
Thank you.