What's the best/common practice for expanding a container pool? I'm aware of the ability to add another directory to the pool, but that would require adding a new VMDK for each expansion. Is that how everyone does it, or is there another way that I'm missing? We assumed (I know!) that we could just expand an LVM and run a command to make TSM see it.

I have done both, adding another directory (lv) and also expanding an existing directory.  Both worked.  Adding the new requires the directory being defined to the container pool, expanding the existing didn't require any TSM commands.

One thing of note, our TSM server is linux and we ran into an inode limit and had to modify the mount to be inode64.  Beyond that it just found the new space and consumed it.  Also, highly recommend getting to TSM 7.1.5 (7.1.6) and enabling container compression if you aren't there yet.  Huge space saver and doesn't appear to impact performance.  The only catch is we had to clean up and replicate data back into the container to compress existing data.

So if I understand you correctly, I should be able to simply expand the disk/volume and TSM automatically picks up on it without commands or a restart? We're currently testing on 7.1.4 (right now we run 6.3.x in production) but I just got the go-ahead to move to 7.1.5 so I'll be doing that this week to see where it lands us.

Did you see any signficant uptick in resource usage with compression enabled?

Yes, the container space just finds the expanded disk/volume and uses it.
Not sure what OS you are running, ours is on linux, the only change we
didn't have in place was inode64 for the mount of the filesystem.
With all the container volumes in the directory, the default was too low
and we exhausted inodes.
Each of our containers are 16TB. Increasing the 8TB volumes to 16TB is
when we banged into that.
But other than that, nothing was done within TSM.

Nothing significant with compression enabled, however, our server is
pretty beefy. 24 proc, 386 GB of RAM.
If resources are tight for memory/cpu, I would take the trade off to get
the compression.
We backup as400s, didn't dedupe at all, compression alone took 54 TB down
to 23. At least there is that.
Same thing for informix backups.
The combination of compression and dedupe for oracle backups is getting us
about 90% reduction in container usage.

Jason Buhr
Systems Engineer Architect
Technical Services
952-897-8104 (work)
612-516-6689 (cell)
Jason.Buhr@spartannash.com





From: David Thomas <storage-ti@lists.imwuc.org>
To: storage-ti@lists.imwuc.org
Date: 07/27/2016 01:20 PM
Subject: [storage-ti] - RE: Question on container pool expansion



So if I understand you correctly, I should be able to simply expand the
disk/volume and TSM automatically picks up on it without commands or a
restart? We're currently testing on 7.1.4 (right now we run 6.3.x in
production) but I just got the go-ahead to move to 7.1.5 so I'll be doing
that this week to see where it lands us.
Did you see any signficant uptick in resource usage with compression
enabled?


Site Links: View post online View mailing list online Start new thread
via email Unsubscribe from this mailing list Manage your subscription


This email has been sent to: jason.buhr@spartannash.com

Thank you very much, Jason! I appreciate the help. I successfully expanded the container directory and TSM picked it up. We also upgraded to 7.1.6 and now have compression enabled.

For future time-travelers, if you're using LVM, make sure to add --resizefs to the end of your lvresize command or else the logical volume will grow, but not the filesystem.