Zoltan SO sorry, my original TSM reference was a hair stale -- try this one: https://www-01.ibm.com/support/knowledgecenter/SSGSG7_7.1.1/com.ibm.itsm.perf.doc/t_perf_diskos_lnx.html
I understand you have constraints, so I am not telling you to do something you cannot do. What I am saying is - you derive more performance benefits with more controllers and spindles - whatever you can do to increase those, will improve your performance (up to a point - you can surpass your motherboard's ability to push traffic through disk controllers but I don't think this is your problem). If you can split your database to 2 filesystems that are on 2 separate controllers, then you have increased the parallelization of disk I/O processing for your database. Even a pair of mirrors on the same array controller would be an improvement over a single mirror on an array controller. Out of curiousity - if your files are all going to tape anyway, what was the purpose for so many TB of disk pool? Can you sacrifice some diskpool in order to improve DB/log performance? You may be better off with a pair of mirrors for your DB, another mirror for logs, another mirror for archivelogs, then you can consume the rest of your slots for hotspares and/or disk pool. If you can't speed up your DB/log processing, don't even think about deduplication, you will spend a LOT of time waiting for the log files to be reconciled against the DB. Best regards, Mike, x7942 RMD IT Client Services On Tue, Feb 2, 2016 at 7:38 AM, Zoltan Forray <zfor...@vcu.edu> wrote: > I understand and we have been using ext4 since it was available. All of my > stgpools are ext4. The DB filesystem is ext3 per the requirements in the > document you referenced for setting up TSM on Linux. > > However, they are spread across 2-ext4 filesystems due to the 16TB limit > for ext4. > > Are you saying I should create multiple ext4 filesystems (i.e. 2TB chunks) > vs the 2-big ones I am currently using? I can't split up the RAID5 array > due to loosing too much storage. > > On Mon, Feb 1, 2016 at 2:05 PM, Ryder, Michael S < > michael_s.ry...@roche.com> > wrote: > > > Hello Zoltan: > > > > I have about 500 volumes spread across a dozen or so EXT4 filesystems, > and > > get performance that operates at the maximum throughput of the hardware. > > > > Here is a good primer on the differences. The bottom line - ext4 can > > perform better than ext3. > > > > http://www.thegeekstuff.com/2011/05/ext2-ext3-ext4/ > > > > Best regards, > > > > Mike, x7942 > > RMD IT Client Services > > > > On Thu, Jan 28, 2016 at 1:43 PM, Zoltan Forray <zfor...@vcu.edu> wrote: > > > > > Mike, > > > > > > Thanks, again. Very helpful. So, did I understand your earlier > > > statement/comment that you disagree with "*Set the LVM read-ahead to 0 > > for > > > all logical volumes on disk systems that provide adaptive read-ahead > > > capabilities, for example, enterprise-type disk systems.*" > > > > > > I also read the statement "*For the Tivoli Storage Manager database and > > > logs, use the ext3 file system.*" Whats up with that? They explain > why > > > you should use ext4 for the storage volumes but no details on ext3 for > > > DB/logs? > > > > > > On Thu, Jan 28, 2016 at 1:05 PM, Ryder, Michael S < > > > michael_s.ry...@roche.com > > > > wrote: > > > > > > > Hi Zoltan > > > > > > > > Here is the reference... I know it is for TSM 7.1, but the reference > is > > > > specific to RHEL and it's filesystems, which is still relevant to the > > > > discussion, I think: > > > > > > > > > > > > > > > > > > http://www-01.ibm.com/support/knowledgecenter/SSGSG7_7.1.0/com.ibm.itsm.perf.doc/t_perf_diskos_lnx.html > > > > > > > > Best regards, > > > > > > > > Mike, x7942 > > > > RMD IT Client Services > > > > > > > > On Thu, Jan 28, 2016 at 11:38 AM, Zoltan Forray <zfor...@vcu.edu> > > wrote: > > > > > > > > > On Wed, Jan 27, 2016 at 10:05 AM, Ryder, Michael S < > > > > > michael_s.ry...@roche.com> wrote: > > > > > > > > > > > Did you follow the docs and disable RHEL's read-ahead > > > > > > caching? If so, you may want to consider enabling it. > > > > > > > > > > > > > > > > Mike, > > > > > > > > > > Can you expand on your statement about RHEL read-ahead cache and > some > > > > > tuning/config document you refer to? We were unaware of such a > > > document > > > > > (or config value). The RHEL read-ahead cache is set to the default > > of > > > > > 128K. Currently all caching is via PERC. > > > > > > > > > > > > > > > -- > > > > > *Zoltan Forray* > > > > > TSM Software & Hardware Administrator > > > > > Xymon Monitor Administrator > > > > > Virginia Commonwealth University > > > > > UCC/Office of Technology Services > > > > > www.ucc.vcu.edu > > > > > zfor...@vcu.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 > > > > > > > > > > > > > > > > > > > > > -- > > > *Zoltan Forray* > > > TSM Software & Hardware Administrator > > > Xymon Monitor Administrator > > > Virginia Commonwealth University > > > UCC/Office of Technology Services > > > www.ucc.vcu.edu > > > zfor...@vcu.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 > > > > > > > > > -- > *Zoltan Forray* > TSM Software & Hardware Administrator > Xymon Monitor Administrator > Virginia Commonwealth University > UCC/Office of Technology Services > www.ucc.vcu.edu > zfor...@vcu.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 >
