strange reclaimation behavor
I have something strange going on with my reclaimations. I have the system issue a command in the afternoons to start reclaiming tapes by dropping the levels to 60%. I then have it issue another command around midnight to raise the levels back to 100%. When I get here in the morning I will usally find that reclaiming is still going on. I have verified that the stop_reclaim scripts are actually running by looking at the actlog for the time period involved. I end up doing a cancel process to get it to stop. I could understand it still running if it was in the middle of a 50-60 gig file but it's only moving small (several meg) files. It's had about eight hours to stop on it's own. I would have thought it would have found an opertunity to stop after eight hours. The contents of all of the scripts involved are correct. I have one starting the tapepool and another to start the copypool and another couple to raise the level back up. I alternate different pools each night. Any ideas here? I'm running 5.2.2 on a Win2k server with 4 LTO2 drives in a PV136T library. David Tyree Enterprise Backup Administrator South Georgia Medical Center 229.333.1155 Confidential Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
AW: strange reclaimation behavor
Copied from Richard Sims ADSM/TSM Quick Facts at http://people.bu.edu/rbs/ADSM.funcdir For an onsite storage pool, the new REClaim value is observed as the next volume is handled. For an offsite storage pool, the new REClaim value is *not* observed prior to the conclusion of the current process. Ref: Admin Guide manual topic Choosing a Reclamation Threshold, Lowering the Migration Threshold. -Ursprüngliche Nachricht- Von: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Im Auftrag von Tyree, David Gesendet: Dienstag, 04. Jänner 2005 15:18 An: ADSM-L@VM.MARIST.EDU Betreff: strange reclaimation behavor I have something strange going on with my reclaimations. I have the system issue a command in the afternoons to start reclaiming tapes by dropping the levels to 60%. I then have it issue another command around midnight to raise the levels back to 100%. When I get here in the morning I will usally find that reclaiming is still going on. I have verified that the stop_reclaim scripts are actually running by looking at the actlog for the time period involved. I end up doing a cancel process to get it to stop. I could understand it still running if it was in the middle of a 50-60 gig file but it's only moving small (several meg) files. It's had about eight hours to stop on it's own. I would have thought it would have found an opertunity to stop after eight hours. The contents of all of the scripts involved are correct. I have one starting the tapepool and another to start the copypool and another couple to raise the level back up. I alternate different pools each night. Any ideas here? I'm running 5.2.2 on a Win2k server with 4 LTO2 drives in a PV136T library. David Tyree Enterprise Backup Administrator South Georgia Medical Center 229.333.1155 Confidential Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Re: strange reclaimation behavor
Hi, When you start reclamation it begins a process and decides which tapes it is going to reclaim based on the value given. These tapes can be seen in the activity log of the server. It will continue to reclaim until it has reclaimed all of the tapes in the list or you cancel the reclamation process. I have seen similar behavior in the migration process as well. If you set a storage pool to migrate (ie. By setting high=0 and low=0) then it will empty it out. If you subsequently reset the values (and the storage pool is now above the low value and below the high value) it will continue to migrate all of the data out. The migration_stop is there to set up the storage pools for the next day's backup. The reclamation stop doesn't seem to be terribly useful. I set my storage pools to a decent value all of the time (something like rec=90). Then on weekends (usually Friday afternoon) I set it to something deeper (currently rec=75 especially for the storage pools on the remote server). Michael Wheelock Integris Health -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Tyree, David Sent: Tuesday, January 04, 2005 8:18 AM To: ADSM-L@VM.MARIST.EDU Subject: strange reclaimation behavor I have something strange going on with my reclaimations. I have the system issue a command in the afternoons to start reclaiming tapes by dropping the levels to 60%. I then have it issue another command around midnight to raise the levels back to 100%. When I get here in the morning I will usally find that reclaiming is still going on. I have verified that the stop_reclaim scripts are actually running by looking at the actlog for the time period involved. I end up doing a cancel process to get it to stop. I could understand it still running if it was in the middle of a 50-60 gig file but it's only moving small (several meg) files. It's had about eight hours to stop on it's own. I would have thought it would have found an opertunity to stop after eight hours. The contents of all of the scripts involved are correct. I have one starting the tapepool and another to start the copypool and another couple to raise the level back up. I alternate different pools each night. Any ideas here? I'm running 5.2.2 on a Win2k server with 4 LTO2 drives in a PV136T library. David Tyree Enterprise Backup Administrator South Georgia Medical Center 229.333.1155 Confidential Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ** This e-mail may contain identifiable health information that is subject to protection under state and federal law. This information is intended to be for the use of the individual named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited and may be punishable by law. If you have received this electronic transmission in error, please notify us immediately by electronic mail (reply). **
Re: strange reclaimation behavor
That's not right. I just proved it, inadvertently. I wanted to deliberately empty out a Disk Storage Pool. I had set lowmig=0 highmig=0 migprocess=4 and it had dutifully mounted 4 tapes and started emptying things out in a hurry. Then 10:00 came, and a daily schedule I had set months ago to shut down migration at that time, happened, and set it to highmig=75 lowmig=25. (Classic self-inflicted foot-shooting.) The effect was to cancel all of the migration processes, even though the storage pool was still 10% full. These process cancelations took effect when each process reached the end of the current file, so they didn't all happen at once although it was fairly quick. Fortunately all the tapes were still mounted so I got them started again quickly. But what I proved (again) was that Migration will stop as soon as you change the thresholds, not when the original lowmig has been reached. If you are seeing something different, I wonder if your client nodes are backing up very large individual files? Reclamation is different from migration. While it does not work on a pre-built list, you are correct that it continues until the end of the volume it is currently reclaiming. Once a reclamation process finishes work on a volume, then the server examines the thresholds all over again to see if it wants to reclaim another tape. So if the reclamation threshold for that storage pool has been changed, it will take effect at that time - at the end of the volume currently being processed, not after all volumes in some list have been processed. As a result, if you are doing this on some schedule, and you need the tape drives at a particular time for something else such as database backup, you can either change the reclamation theshold several hours in advance, or develop an OS script to query the process, parse the result, and cancel it by process number. Even then, the reclamation process cancelation will not take effect until the end of the file currently being processed. The strategy I use to make sure I get the tape drives for database backup at the scheduled time, is to run migration between reclamation and DB backup, since migration can stop itself and free the drives pretty quickly, in contrast to reclamation. Roger Deschner University of Illinois at Chicago [EMAIL PROTECTED] ==I have not lost my mind -- it is backed up on tape somewhere.= Date: Jan 04, 09:45 From: Wheelock, Michael D nobody at nowhere.com Hi, When you start reclamation it begins a process and decides which tapes it is going to reclaim based on the value given. These tapes can be seen in the activity log of the server. It will continue to reclaim until it has reclaimed all of the tapes in the list or you cancel the reclamation process. =20 I have seen similar behavior in the migration process as well. If you set a storage pool to migrate (ie. By setting high=3D0 and low=3D0) then = it will empty it out. If you subsequently reset the values (and the storage pool is now above the low value and below the high value) it will continue to migrate all of the data out. The migration_stop is there to set up the storage pools for the next day's backup. The reclamation stop doesn't seem to be terribly useful. I set my storage pools to a decent value all of the time (something like rec=3D90). Then on weekends (usually Friday afternoon) I set it to something deeper (currently rec=3D75 especially for the storage pools on the remote server). =20 Michael Wheelock Integris Health -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of Tyree, David Sent: Tuesday, January 04, 2005 8:18 AM To: ADSM-L AT VM.MARIST DOT EDU Subject: strange reclaimation behavor I have something strange going on with my reclaimations. I have the system issue a command in the afternoons to start reclaiming tapes by dropping the levels to 60%. I then have it issue another command around midnight to raise the levels back to 100%. When I get here in the morning I will usally find that reclaiming is still going on. I have verified that the stop_reclaim scripts are actually running by looking at the actlog for the time period involved. I end up doing a cancel process to get it to stop. I could understand it still running if it was in the middle of a 50-60 gig file but it's only moving small (several meg) files. It's had about eight hours to stop on it's own. I would have thought it would have found an opertunity to stop after eight hours. The contents of all of the scripts involved are correct. I have one starting the tapepool and another to start the copypool and another couple to raise the level back up. I alternate different pools each night. Any ideas here? I'm running 5.2.2 on a Win2k server with 4 LTO2 drives in a PV136T library. David Tyree Enterprise Backup Administrator South Georgia Medical Center 229.333.1155
Re: strange reclaimation behavor
, not when the original lowmig has been reached. If you are seeing something different, I wonder if your client nodes are backing up very large individual files? Reclamation is different from migration. While it does not work on a pre-built list, you are correct that it continues until the end of the volume it is currently reclaiming. Once a reclamation process finishes work on a volume, then the server examines the thresholds all over again to see if it wants to reclaim another tape. So if the reclamation threshold for that storage pool has been changed, it will take effect at that time - at the end of the volume currently being processed, not after all volumes in some list have been processed. As a result, if you are doing this on some schedule, and you need the tape drives at a particular time for something else such as database backup, you can either change the reclamation theshold several hours in advance, or develop an OS script to query the process, parse the result, and cancel it by process number. Even then, the reclamation process cancelation will not take effect until the end of the file currently being processed. The strategy I use to make sure I get the tape drives for database backup at the scheduled time, is to run migration between reclamation and DB backup, since migration can stop itself and free the drives pretty quickly, in contrast to reclamation. Roger Deschner University of Illinois at Chicago [EMAIL PROTECTED] ==I have not lost my mind -- it is backed up on tape somewhere.= Date: Jan 04, 09:45 From: Wheelock, Michael D nobody at nowhere.com Hi, When you start reclamation it begins a process and decides which tapes it is going to reclaim based on the value given. These tapes can be seen in the activity log of the server. It will continue to reclaim until it has reclaimed all of the tapes in the list or you cancel the reclamation process. =20 I have seen similar behavior in the migration process as well. If you set a storage pool to migrate (ie. By setting high=3D0 and low=3D0) then = it will empty it out. If you subsequently reset the values (and the storage pool is now above the low value and below the high value) it will continue to migrate all of the data out. The migration_stop is there to set up the storage pools for the next day's backup. The reclamation stop doesn't seem to be terribly useful. I set my storage pools to a decent value all of the time (something like rec=3D90). Then on weekends (usually Friday afternoon) I set it to something deeper (currently rec=3D75 especially for the storage pools on the remote server). =20 Michael Wheelock Integris Health -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of Tyree, David Sent: Tuesday, January 04, 2005 8:18 AM To: ADSM-L AT VM.MARIST DOT EDU Subject: strange reclaimation behavor I have something strange going on with my reclaimations. I have the system issue a command in the afternoons to start reclaiming tapes by dropping the levels to 60%. I then have it issue another command around midnight to raise the levels back to 100%. When I get here in the morning I will usally find that reclaiming is still going on. I have verified that the stop_reclaim scripts are actually running by looking at the actlog for the time period involved. I end up doing a cancel process to get it to stop. I could understand it still running if it was in the middle of a 50-60 gig file but it's only moving small (several meg) files. It's had about eight hours to stop on it's own. I would have thought it would have found an opertunity to stop after eight hours. The contents of all of the scripts involved are correct. I have one starting the tapepool and another to start the copypool and another couple to raise the level back up. I alternate different pools each night. Any ideas here? I'm running 5.2.2 on a Win2k server with 4 LTO2 drives in a PV136T library. David Tyree Enterprise Backup Administrator South Georgia Medical Center 229.333.1155 Confidential Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. *= * This e-mail may contain identifiable health information that is subject t= o protection=20 under state and federal law. This information is intended to be for the u= se of the=20 individual named above. If you are not the intended recipient, be aware t= hat any=20 disclosure, copying, distribution or use of the contents of this informat= ion is prohibited=20 and may be punishable by law. If you have received
Re: strange reclaimation behavor
they didn't all happen at once although it was fairly quick. Fortunately all the tapes were still mounted so I got them started again quickly. But what I proved (again) was that Migration will stop as soon as you change the thresholds, not when the original lowmig has been reached. If you are seeing something different, I wonder if your client nodes are backing up very large individual files? Reclamation is different from migration. While it does not work on a pre-built list, you are correct that it continues until the end of the volume it is currently reclaiming. Once a reclamation process finishes work on a volume, then the server examines the thresholds all over again to see if it wants to reclaim another tape. So if the reclamation threshold for that storage pool has been changed, it will take effect at that time - at the end of the volume currently being processed, not after all volumes in some list have been processed. As a result, if you are doing this on some schedule, and you need the tape drives at a particular time for something else such as database backup, you can either change the reclamation theshold several hours in advance, or develop an OS script to query the process, parse the result, and cancel it by process number. Even then, the reclamation process cancelation will not take effect until the end of the file currently being processed. The strategy I use to make sure I get the tape drives for database backup at the scheduled time, is to run migration between reclamation and DB backup, since migration can stop itself and free the drives pretty quickly, in contrast to reclamation. Roger Deschner University of Illinois at Chicago [EMAIL PROTECTED] ==I have not lost my mind -- it is backed up on tape somewhere.= Date: Jan 04, 09:45 From: Wheelock, Michael D nobody at nowhere.com Hi, When you start reclamation it begins a process and decides which tapes it is going to reclaim based on the value given. These tapes can be seen in the activity log of the server. It will continue to reclaim until it has reclaimed all of the tapes in the list or you cancel the reclamation process. =20 I have seen similar behavior in the migration process as well. If you set a storage pool to migrate (ie. By setting high=3D0 and low=3D0) then = it will empty it out. If you subsequently reset the values (and the storage pool is now above the low value and below the high value) it will continue to migrate all of the data out. The migration_stop is there to set up the storage pools for the next day's backup. The reclamation stop doesn't seem to be terribly useful. I set my storage pools to a decent value all of the time (something like rec=3D90). Then on weekends (usually Friday afternoon) I set it to something deeper (currently rec=3D75 especially for the storage pools on the remote server). =20 Michael Wheelock Integris Health -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of Tyree, David Sent: Tuesday, January 04, 2005 8:18 AM To: ADSM-L AT VM.MARIST DOT EDU Subject: strange reclaimation behavor I have something strange going on with my reclaimations. I have the system issue a command in the afternoons to start reclaiming tapes by dropping the levels to 60%. I then have it issue another command around midnight to raise the levels back to 100%. When I get here in the morning I will usally find that reclaiming is still going on. I have verified that the stop_reclaim scripts are actually running by looking at the actlog for the time period involved. I end up doing a cancel process to get it to stop. I could understand it still running if it was in the middle of a 50-60 gig file but it's only moving small (several meg) files. It's had about eight hours to stop on it's own. I would have thought it would have found an opertunity to stop after eight hours. The contents of all of the scripts involved are correct. I have one starting the tapepool and another to start the copypool and another couple to raise the level back up. I alternate different pools each night. Any ideas here? I'm running 5.2.2 on a Win2k server with 4 LTO2 drives in a PV136T library. David Tyree Enterprise Backup Administrator South Georgia Medical Center 229.333.1155 Confidential Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. *= * This e-mail may
Re: strange reclaimation behavor
, and a daily schedule I had set months ago to shut down migration at that time, happened, and set it to highmig=75 lowmig=25. (Classic self-inflicted foot-shooting.) The effect was to cancel all of the migration processes, even though the storage pool was still 10% full. These process cancelations took effect when each process reached the end of the current file, so they didn't all happen at once although it was fairly quick. Fortunately all the tapes were still mounted so I got them started again quickly. But what I proved (again) was that Migration will stop as soon as you change the thresholds, not when the original lowmig has been reached. If you are seeing something different, I wonder if your client nodes are backing up very large individual files? Reclamation is different from migration. While it does not work on a pre-built list, you are correct that it continues until the end of the volume it is currently reclaiming. Once a reclamation process finishes work on a volume, then the server examines the thresholds all over again to see if it wants to reclaim another tape. So if the reclamation threshold for that storage pool has been changed, it will take effect at that time - at the end of the volume currently being processed, not after all volumes in some list have been processed. As a result, if you are doing this on some schedule, and you need the tape drives at a particular time for something else such as database backup, you can either change the reclamation theshold several hours in advance, or develop an OS script to query the process, parse the result, and cancel it by process number. Even then, the reclamation process cancelation will not take effect until the end of the file currently being processed. The strategy I use to make sure I get the tape drives for database backup at the scheduled time, is to run migration between reclamation and DB backup, since migration can stop itself and free the drives pretty quickly, in contrast to reclamation. Roger Deschner University of Illinois at Chicago [EMAIL PROTECTED] ==I have not lost my mind -- it is backed up on tape somewhere.= Date: Jan 04, 09:45 From: Wheelock, Michael D nobody at nowhere.com Hi, When you start reclamation it begins a process and decides which tapes it is going to reclaim based on the value given. These tapes can be seen in the activity log of the server. It will continue to reclaim until it has reclaimed all of the tapes in the list or you cancel the reclamation process. =20 I have seen similar behavior in the migration process as well. If you set a storage pool to migrate (ie. By setting high=3D0 and low=3D0) then = it will empty it out. If you subsequently reset the values (and the storage pool is now above the low value and below the high value) it will continue to migrate all of the data out. The migration_stop is there to set up the storage pools for the next day's backup. The reclamation stop doesn't seem to be terribly useful. I set my storage pools to a decent value all of the time (something like rec=3D90). Then on weekends (usually Friday afternoon) I set it to something deeper (currently rec=3D75 especially for the storage pools on the remote server). =20 Michael Wheelock Integris Health -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of Tyree, David Sent: Tuesday, January 04, 2005 8:18 AM To: ADSM-L AT VM.MARIST DOT EDU Subject: strange reclaimation behavor I have something strange going on with my reclaimations. I have the system issue a command in the afternoons to start reclaiming tapes by dropping the levels to 60%. I then have it issue another command around midnight to raise the levels back to 100%. When I get here in the morning I will usally find that reclaiming is still going on. I have verified that the stop_reclaim scripts are actually running by looking at the actlog for the time period involved. I end up doing a cancel process to get it to stop. I could understand it still running if it was in the middle of a 50-60 gig file but it's only moving small (several meg) files. It's had about eight hours to stop on it's own. I would have thought it would have found an opertunity to stop after eight hours. The contents of all of the scripts involved are correct. I have one starting the tapepool and another to start the copypool and another couple to raise the level back up. I alternate different pools each night. Any ideas here? I'm running 5.2.2 on a Win2k server with 4 LTO2 drives in a PV136T library. David Tyree Enterprise Backup Administrator South Georgia Medical Center 229.333.1155 Confidential Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain
