ADSM-L

[ADSM-L] When can too many disk volumes be detrimental

2016-01-26 15:57:52
Subject: [ADSM-L] When can too many disk volumes be detrimental
From: Zoltan Forray <zforray AT VCU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 26 Jan 2016 15:55:59 -0500
RedHat Linux 6.7 with TSM 6.3.5.100

Back in the "good old days" of ADSM/TSM, I was always taught that the more
TSM disk volumes you had, the better since TSM would spread the I/O's
across the volumes in a somewhat balanced manner, to improve performance.
Yes I realize this was with multiple physical spindles.

Now with bigger hard drives, I am wondering if having tooooo many volumes
is hurting I/O performance. Here is the situation.

We recently replaced 2-TSM servers that had rolled off warranty (4-year old
Dell T710 systems) that had 8-600GB internal disk. The new servers are T720
systems with *6TB* drives (both have 96GB RAM).  So I went from roughly
*5TB* of internal disk storage for inbound backups to *30TB*. I went from
multiple 300GB disk volumes to 30-1TB volumes. Plus add 20TB of SAN space
gives me 40-disk volumes.

The reasons for my concern is the time it takes to move the data from disk
to tape.  I am seeing it take 11-hours to empty (move data) a 100% full 1TB
disk volume.  To me, this is very, very slow.

We had a hard disk failure that for some reason (all RAID5) took out part
of the OS partition and damaged the /tsmlog and /tsmarchlog filesystems,
forcing me to restore from a 8-hour old DB backup (even Dell said this
should not have happened so they replaced the drive and PERC controller).
It has taken more than *2-weeks* of non-stop audit, move data of
non-damaged files, restore of damaged files - processes against the
internal disk volumes. I recorded some audits running 32-hours).

As I redefine/rebuild the disk volumes, I am starting to create 2 and 3TB
volumes to see if that helps improve performance.

So, your thoughts/ideas/suggestions on what might be going on here.

--
*Zoltan Forray*
TSM Software & Hardware Administrator
Xymon Monitor Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
www.ucc.vcu.edu
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