ADSM-L

Re: [ADSM-L] TSM performance very poor, Recovery log is being pinned

2007-08-01 00:05:34
Subject: Re: [ADSM-L] TSM performance very poor, Recovery log is being pinned
From: Stuart Lamble <adsm AT CAROUSEL.ITS.MONASH.EDU DOT AU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 1 Aug 2007 13:59:16 +1000
On 29/07/2007, at 10:03 PM, Stapleton, Mark wrote:

From: ADSM: Dist Stor Manager on behalf of Craig Ross
TSM is installed on Solaris 10
This is something that popped right out for me. Do you have your
storage pools located on raw logical volumes or mounted
filesystems? If the latter, that might be your problem. Solaris has
traditionally had incredibly poor throughput performance on mounted
filesystems.

You might give thought to rebuilding those storage pools on raw
logical volumes. Of course, that will require that you completely
flush all data from your disk storage pools to tape storage pools
first, so as not to lose client data.
A small trap for young players: TSM has constraints in place to stop
it writing to cylinder 0 of a raw volume on Solaris. If you direct
TSM at slice 2, or some other slice that includes cylinder 0, it will
barf, and the error message is rather cryptic (sorry for the
vagueness; it's been a year or so since I bumped into this. At the
time, I was working on the storage pool volume level, but I would
expect to see similar behaviour for a DB or log volume.)

Workaround is simple: make slice 0 include the entire disk starting
from cylinder 1, and use slice 0 as the raw volume.

I am not going to enter into a debate about the relative merits of
raw volumes versus files on filesystems, as I have insufficient
direct knowledge to judge either way (I'm trusting a more senior
colleague to make the right call there. :)

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