Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Slow\s+Offsite\s+Reclamation\s+\(Was\s+Tape\s+drive\s+recomendations\)\s*$/: 8 ]

Total 8 documents matching your query.

1. Re: Slow Offsite Reclamation (Was Tape drive recomendations) (score: 1)
Author: "Rushforth, Tim" <TRushfor AT CITY.WINNIPEG.MB DOT CA>
Date: Fri, 1 Nov 2002 09:25:53 -0600
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 IC1592
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2002-11/msg00016.html (14,916 bytes)

2. Re: Slow Offsite Reclamation (Was Tape drive recomendations) (score: 1)
Author: Tab Trepagnier <Tab.Trepagnier AT LAITRAM DOT COM>
Date: Fri, 1 Nov 2002 17:19:25 -0600
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 po
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2002-11/msg00045.html (15,677 bytes)

3. Re: Slow Offsite Reclamation (Was Tape drive recomendations) (score: 1)
Author: "Rushforth, Tim" <TRushfor AT CITY.WINNIPEG.MB DOT CA>
Date: Fri, 1 Nov 2002 21:58:46 -0600
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
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2002-11/msg00047.html (14,258 bytes)

4. Re: Slow Offsite Reclamation (Was Tape drive recomendations) (score: 1)
Author: DFrance <DFrance-TSM AT ATT DOT NET>
Date: Fri, 1 Nov 2002 23:18:02 -0800
So,,, the upshot is, for good performance of OFFSITE reclamation: - empty the DISK (ie, RANDOM) storage pool(s) that feed any offsite/copy-pool before running reclamation. This, loosely translates to
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2002-11/msg00049.html (16,694 bytes)

5. Re: Slow Offsite Reclamation (Was Tape drive recomendations) (score: 1)
Author: Bill Boyer <bill.boyer AT VERIZON DOT NET>
Date: Mon, 4 Nov 2002 11:22:11 -0500
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. W
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2002-11/msg00102.html (14,920 bytes)

6. Re: Slow Offsite Reclamation (Was Tape drive recomendations) (score: 1)
Author: Dave Canan <ddcanan AT ATTGLOBAL DOT NET>
Date: Mon, 4 Nov 2002 12:13:45 -0800
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. Bill Boyer DSS,Inc. We're at 4.20 and the prob
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2002-11/msg00105.html (15,492 bytes)

7. Re: Slow Offsite Reclamation (Was Tape drive recomendations) (score: 1)
Author: "Rushforth, Tim" <TRushfor AT CITY.WINNIPEG.MB DOT CA>
Date: Mon, 4 Nov 2002 14:43:44 -0600
Excellent!!! Thank you IBM! We will soon be able to use our full Disk Pool! This problem is addressed by APAR IC34386, which I believe is slated for release soon (within the next week, hopefully) the
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2002-11/msg00106.html (11,917 bytes)

8. Re: Slow Offsite Reclamation (Was Tape drive recomendations) (score: 1)
Author: David Longo <David.Longo AT HEALTH-FIRST DOT ORG>
Date: Mon, 4 Nov 2002 15:58:11 -0500
And the users with LTO tapes will get full speed on Reclamation! Won't have to tweak on disk pool as much for it to work! David Longo Excellent!!! Thank you IBM! We will soon be able to use our full
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2002-11/msg00107.html (13,290 bytes)


This search system is powered by Namazu