This problem is addressed by APAR IC34386, which I believe is slated for release soon (within the next week, hopefully) the next patch level for V5.1.5.
At 11:22 AM 11/4/2002 -0500, you wrote:
This is because when the primary location of a file to be reclaimed in on DISK random access storage pool, TSM processes these files one-at-a-time! The MOVESIZETHRESH and MOVEBATCHSIZE are ignored. We opened an APAR on this a couple years ago and were told "working as designed". Bill Boyer DSS,Inc. -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@;VM.MARIST.EDU]On Behalf Of Rushforth, Tim Sent: Friday, November 01, 2002 10:59 PM To: [EMAIL PROTECTED] Subject: Re: Slow Offsite Reclamation (Was Tape drive recomendations) We're at 4.20 and the problem is still there. I implore everyone who is having this problem or might have this problem to submit a requirement to IBM (I have already). As the APAR suggests it is not a trivial code change. Perhaps if enough people complain IBM will get this right. (There are a lot of "disk based" backup products coming that may perform better than this ...) -----Original Message----- From: Tab Trepagnier [mailto:Tab.Trepagnier@;LAITRAM.COM] Sent: November 1, 2002 5:19 PM To: [EMAIL PROTECTED] Subject: Re: Slow Offsite Reclamation (Was Tape drive recomendations) Tim, I guarantee that the problem still exists in 4.1.5.0. After seeing my TSM system take 12 hours to reclaim 100 MB of copypool data I used that APAR as a reference and changed my directory disk pool to FILE volumes. The performance improvement was dramatic. I use DLT 8000 for copypool, and when the source tape is LTO or 3575XL, I'm seeing the full 8 MB/s capacity of the DLTs. When reclaiming directories, the MB/s throughput is still fairly low, but the object throughput is on the order of hundreds / sec. Tab Trepagnier TSM Administrator Laitram Corporation "Rushforth, Tim" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 11/01/2002 09:25 AM Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] cc: Subject: Re: Slow Offsite Reclamation (Was Tape drive recomendations) Yes! An old APAR cover's this issue, see below. When you are running offsite reclamation watch the throughput when it is reading from disk as opposed to reading from tape. It just crawls. Apar IC15925: -------------------------------------------------------------------- ERROR DESCRIPTION During an offsite reclamation process; where files are being transfered from disk to tape. ADSM fails to group the files together into transaction groups. Instead the files are processed sequentially. Hence a file will be reclaimed and committed before the next file will be process. ADSM needs to honor the movebatchsize and movesizethresh options in the server options file, so that the files will be grouped together properly for reclimation. As a note, this problem will only be seen where off-site reclamation is occuring from disk to tape. COMMENTS: After taking a very close look at the solution for this APAR, it was determined that the code needed for this performance enhancement is significant because it requires a restructure in the offsite reclamation transaction processing. A requirement can be taken to include this performance improvement in the next release or version. -------------------------------------------------------------------- Tim Rushforth City of Winnipeg
Dave Canan IBM Advanced Technical Support [EMAIL PROTECTED]
