ADSM-L

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

2016-02-02 07:41:00
Subject: Re: [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, 2 Feb 2016 07:38:56 -0500
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.ryder AT roche DOT 
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 <zforray AT vcu DOT 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.ryder AT roche DOT 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 <zforray AT vcu DOT edu>
> wrote:
> > >
> > > > On Wed, Jan 27, 2016 at 10:05 AM, Ryder, Michael S <
> > > > michael_s.ryder AT roche DOT 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
> > > > 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
> > > >
> > >
> >
> >
> >
> > --
> > *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
> >
>



--
*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

<Prev in Thread] Current Thread [Next in Thread>