In a somewhat related note we too have had problems with reclamation using
disk.  We had an idea that we thought would help restores.  We had a TSM
server set up with a ton of disk.  Enough to hold 14 days worth of nightly
incremental backup data.  We believed that 99% of our daily restores would
come from here.  For all the obvious reasons this would be much quicker than
having the restores come from tape.  However, we hit the major reclamation
snag.  Our reclamation processes that would run in a matter of hours
literally ran for their entire 15 hour window without reclaiming even 50 %
of the volumes.

We opened a call with Tivoli and we were also told that this was working as
designed.  We figured it wouldn't be very likely that they would go through
the work of changing this so we never put in a design change request.  The
request would be to create a switch that when enabled would set a parm like
"reclaim from tape only". This would allow for large cached disk pools
without the reclamation issues.

Is there anyone else who would like this change?  We ask only because if
many of us would like it we may have more weight with Tivoli.

______________________________
David Beardsley
Kimberly-Clark Corporation
E-Mail:  [EMAIL PROTECTED]
Phone:   (920) 721-6127


-----Original Message-----
From: William Boyer [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 28, 2000 9:14 AM
To: [EMAIL PROTECTED]
Subject: Re: DIRMC - disadvantages only?


Another disadvantage is reclamation of the copypool for the DIRMC disk pool.
If the primary pool is a disk pool, then TSM server only reads 1
file/directory at a time during reclamation of the offsite copypool for the
DIRMC primary pool. This makes the reclamation process REAL slow! Tivoli
says 'working as designed' and would only take an enhancement request on it,
not an APAR. Originally my storage pool was:

DIRPOOL primary DISK
DIRCOPYPOOL     copypool TAPE

To get around this 'feature' a co-worker of mine came up with this new
stgpool structure:

DIRPOOL primary DISK: NEXTPOOL->DIRFILE
DIRFILE primary SEQUENTIAL on DISK
DIRCOPYPOOL     copypool TAPE

The DIRPOOL is small, only 50MB. The DIRFILE is set to 100MB filesize. The
client backkups put the directories in the DIRPOOL and then the daily server
processes are:

BA STG DIRPOOL DIRCOPYPOOL
BA STG DIRFILE DIRCOPYPOOL
UPD STG DIRPOOL HI=0 LO=0       (Migrate for DIRFILE)

This way when reclamation occurs on DIRCOPYPOOL, the primary pool is a
SEQUENTIAL pool and then TSM reads them in batches. It's a LOT faster this
way.

One problem I encountered with DIRMC was with some of the older TSM and ADSM
clients. I was getting errors on the client when trying to send a directory
entry that the  server was out of storage pool space in the DIRPOOL. Turns
out this is an APAR (Can't remember the number) in the client where it
calculates the size incorrectly on NT clients with security assigned for
directories. To fix this upgrade to the latest client, or add
SKIPNTPERMISSIONS YES to the DSM.OPT file on the client.

Bill Boyer
DSS, Inc.

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of
France, Don G (Pace)
Sent: Monday, November 27, 2000 4:24 PM
To: [EMAIL PROTECTED]
Subject: Re: DIRMC - disadvantages only?

< clip >

------------------------------------------------------------------------------
This e-mail is intended for the use of the addressee(s) only and may contain 
privileged, confidential, or proprietary information that is exempt from disclosure 
under law.  If you have received this message in error, please inform us promptly by 
reply e-mail, then delete the e-mail and destroy any printed copy.   Thank you.

==============================================================================

Reply via email to