Eric, Ok, you got my attention now! What "bug" should I be losing sleep over?
-steve -----Original Message----- From: Loon, E.J. van - SPLXM [mailto:[EMAIL PROTECTED] Sent: Friday, January 14, 2005 4:07 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: Enabling caching to shorten housekeeping Hi Steve (and other who replied)! The risk of fragmentation sounds reasonable. I will keep that in mind, thanks! Yes, I'm running two storage pool backups at the same time (my copypool library only has two drives) and buying more drives is not an option, since it's a 3494 frame. Expanding requires buying a drive frame and 3590 drives, which are very expensive. This while my current TSM environment will have to hold on for about half a year. We are currently working on a drastic TSM redesign. We are planning for a TSM 5.3 server on AIX 5.2 on a brand new P-Series machine. We will attach more than one (probably 3) DS-series (formerly known as FastT) SATA subsystems with a total amount of 200 Tb. online storage to accommodate for our primary (file device class) storage pool. We only ran into a nasty bug when using the file device class, so I hope IBM will turn my PMR in an APAR and fix it as soon as possible... Kindest regards, Eric van Loon KLM Royal Dutch Airlines -----Original Message----- From: Steve Schaub [mailto:[EMAIL PROTECTED] Sent: Thursday, January 13, 2005 21:32 To: ADSM-L@VM.MARIST.EDU Subject: Re: Enabling caching to shorten housekeeping Eric, The issues we had when we had caching turned on were: 1. Fragmentation of the the diskpool which led to a general slowdown in processes. This can be minimized if you have a regular schedule of flushing the cache (turn it off and migrate down to zero). 2. TDP agents don't always play nice with diskpool using caching - some algorithim issue that doesn't free up a big enough block and then kills the backup when it runs out of room in the pool. I'm assuming you are already multi-threading your stgpool backup and migration, so the only suggestions I can offer are; 1. buy more tape drives and increase the multi-threads 2. buy tons of cheap disk and implement file-based stgpools. This is the approach we took and it cut our total housekeeping elapsed time by 75%. Good luck! Steve Schaub Computer Storage Systems Engineer II Haworth, Inc 616-393-1457 (desk) 616-886-8821 (cell) [EMAIL PROTECTED] "Trials are inevitable. We can curse them and grow bitter, or harvest them and grow stronger" -----Original Message----- From: Loon, E.J. van - SPLXM [mailto:[EMAIL PROTECTED] Sent: Thursday, January 13, 2005 10:27 AM To: ADSM-L@VM.MARIST.EDU Subject: Enabling caching to shorten housekeeping Hi *SM-ers! I'm currently struggling with the fact that I cannot run a backup stgpool diskpool and a migrate diskpool (to empty it out for the next client backup cycle) sequentially no more. Migration would run well into the evening and I would like it to be ready at 18:00 hours. I'm thinking about turning on caching for my diskpool. If it works like I hope, TSM migration empties out the diskpool, but leaving the actual data behind, so a backup stgpool diskpool uses these cached copies, instead of mounting all the tapes during a subsequent backup stgpool tapepool. In that case, I can run migration and backup stgpool at the same time. Is TSM working like this or will a cached object, once (logically) migrated, be backed up from tape? Thank you very much for your reply in advance! Kindest regards, Eric van Loon KLM Royal Dutch Airlines ********************************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. **********************************************************************
