Re: 3584 upgrade: 3592-E05 to 3592-E07
Increasing reusedelay and ejecting when tape in PENDING, That's a really good idea! Thank! Rick -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Prather, Wanda Sent: Thursday, June 19, 2014 11:51 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: 3584 upgrade: 3592-E05 to 3592-E07 I agree. As long as there are lots of JC tapes on the scratch list, I believe the default algorithm is to round-robin the scratch list, so the old tapes that free up will likely be at the bottom of the scratch list and will likely not get used before you check them out. And I like the idea of increasing the reusedelay, that should give you even more leeway. If you still have problems, there is a software solution: Update your storage pools to maxscratch=0 Use the DEFINE VOLUME command to bind JC tapes to the storage pools, and check them in as PRIVATE. That way no pools will be grabbing scratch tapes at all. When all your JA/JB tapes are removed, update the stgpools to maxscratch= and go back to using a scratch pool again. W -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Thomas Denier Sent: Thursday, June 19, 2014 2:46 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] 3584 upgrade: 3592-E05 to 3592-E07 I'm not sure the problem is as bad as you think. Automatic tape libraries tend to manage scratch tapes first-in first-out in an effort to distribute tape wear evenly. My guess is that your library will use all of the JC volumes inserted at the start of the conversion before using any of the JA or JB volumes scratched after that. If you later clean out scratched JA and JB volumes and add JC scratch volumes, my guess is that the new batch of JC volumes will be used before any JA or JB volumes scratched after that. For storage pool volumes you could eject JA and JB volumes in PENDING status to eliminate any worries about the volumes being reused. You could temporarily increase the reuse delay to give you a bigger window of opportunity for ejecting volumes and/or maintain the normal degree of readiness for restoring older versions of the TSM database. Thomas Denier Thomas Jefferson University Hospital -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Rhodes, Richard L. Sent: Thursday, June 19, 2014 12:19 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] 3584 upgrade: 3592-E05 to 3592-E07 Hi, This weekend we are upgrading all of our tape drives (in 2 libraries) from 3592-E05 (TS1120) to 3592-E07 (TS1140). The libraries currently have a mix of JA and JB media. We will be migrating over time to all new JC media. JA tapes are READONLY on 3592-E07 drives. JB tapes are READ/WRITE on 3592-E07 drives. The plan is to: - Export out of the lib all current scratch JA/JB media. - Mark all existing JA/JB media ReadOnly. - Insert lots of new JC media. - TSM will write to the new JC tapes. - As JA/JB tapes drop to scratch, export them out of the Library, and insert more JC media. When JA/JB tapes drop to SCRATCH status, I'm not sure I will always be able to export them before TSM might try and reuse them. If TSM tries to use a JB tape, that is OK - it will work. But what if TSM selects a JA tape and tries to use it. That would fail since 3592-E07 drives can READ JA media but NOT WRITE to them. Q) Is TSM smart enough to not load a JA media into a 3592-E07 drive for writing? TSM has the media_type of all tapes (q libvol f=d), so I would think it should know not to do this. Thanks Rick - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message. The information contained in this transmission contains privileged and confidential information. It is intended only for the use of the person named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. CAUTION: Intended recipients should NOT use email communication for emergent or urgent health care matters.
Re: 3584 upgrade: 3592-E05 to 3592-E07
I agree. As long as there are lots of JC tapes on the scratch list, I believe the default algorithm is to round-robin the scratch list, so the old tapes that free up will likely be at the bottom of the scratch list and will likely not get used before you check them out. And I like the idea of increasing the reusedelay, that should give you even more leeway. If you still have problems, there is a software solution: Update your storage pools to maxscratch=0 Use the DEFINE VOLUME command to bind JC tapes to the storage pools, and check them in as PRIVATE. That way no pools will be grabbing scratch tapes at all. When all your JA/JB tapes are removed, update the stgpools to maxscratch= and go back to using a scratch pool again. W -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Thomas Denier Sent: Thursday, June 19, 2014 2:46 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] 3584 upgrade: 3592-E05 to 3592-E07 I'm not sure the problem is as bad as you think. Automatic tape libraries tend to manage scratch tapes first-in first-out in an effort to distribute tape wear evenly. My guess is that your library will use all of the JC volumes inserted at the start of the conversion before using any of the JA or JB volumes scratched after that. If you later clean out scratched JA and JB volumes and add JC scratch volumes, my guess is that the new batch of JC volumes will be used before any JA or JB volumes scratched after that. For storage pool volumes you could eject JA and JB volumes in PENDING status to eliminate any worries about the volumes being reused. You could temporarily increase the reuse delay to give you a bigger window of opportunity for ejecting volumes and/or maintain the normal degree of readiness for restoring older versions of the TSM database. Thomas Denier Thomas Jefferson University Hospital -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Rhodes, Richard L. Sent: Thursday, June 19, 2014 12:19 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] 3584 upgrade: 3592-E05 to 3592-E07 Hi, This weekend we are upgrading all of our tape drives (in 2 libraries) from 3592-E05 (TS1120) to 3592-E07 (TS1140). The libraries currently have a mix of JA and JB media. We will be migrating over time to all new JC media. JA tapes are READONLY on 3592-E07 drives. JB tapes are READ/WRITE on 3592-E07 drives. The plan is to: - Export out of the lib all current scratch JA/JB media. - Mark all existing JA/JB media ReadOnly. - Insert lots of new JC media. - TSM will write to the new JC tapes. - As JA/JB tapes drop to scratch, export them out of the Library, and insert more JC media. When JA/JB tapes drop to SCRATCH status, I'm not sure I will always be able to export them before TSM might try and reuse them. If TSM tries to use a JB tape, that is OK - it will work. But what if TSM selects a JA tape and tries to use it. That would fail since 3592-E07 drives can READ JA media but NOT WRITE to them. Q) Is TSM smart enough to not load a JA media into a 3592-E07 drive for writing? TSM has the media_type of all tapes (q libvol f=d), so I would think it should know not to do this. Thanks Rick - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message. The information contained in this transmission contains privileged and confidential information. It is intended only for the use of the person named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. CAUTION: Intended recipients should NOT use email communication for emergent or urgent health care matters.
Re: 3584 upgrade: 3592-E05 to 3592-E07
I'm not sure the problem is as bad as you think. Automatic tape libraries tend to manage scratch tapes first-in first-out in an effort to distribute tape wear evenly. My guess is that your library will use all of the JC volumes inserted at the start of the conversion before using any of the JA or JB volumes scratched after that. If you later clean out scratched JA and JB volumes and add JC scratch volumes, my guess is that the new batch of JC volumes will be used before any JA or JB volumes scratched after that. For storage pool volumes you could eject JA and JB volumes in PENDING status to eliminate any worries about the volumes being reused. You could temporarily increase the reuse delay to give you a bigger window of opportunity for ejecting volumes and/or maintain the normal degree of readiness for restoring older versions of the TSM database. Thomas Denier Thomas Jefferson University Hospital -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Rhodes, Richard L. Sent: Thursday, June 19, 2014 12:19 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] 3584 upgrade: 3592-E05 to 3592-E07 Hi, This weekend we are upgrading all of our tape drives (in 2 libraries) from 3592-E05 (TS1120) to 3592-E07 (TS1140). The libraries currently have a mix of JA and JB media. We will be migrating over time to all new JC media. JA tapes are READONLY on 3592-E07 drives. JB tapes are READ/WRITE on 3592-E07 drives. The plan is to: - Export out of the lib all current scratch JA/JB media. - Mark all existing JA/JB media ReadOnly. - Insert lots of new JC media. - TSM will write to the new JC tapes. - As JA/JB tapes drop to scratch, export them out of the Library, and insert more JC media. When JA/JB tapes drop to SCRATCH status, I'm not sure I will always be able to export them before TSM might try and reuse them. If TSM tries to use a JB tape, that is OK - it will work. But what if TSM selects a JA tape and tries to use it. That would fail since 3592-E07 drives can READ JA media but NOT WRITE to them. Q) Is TSM smart enough to not load a JA media into a 3592-E07 drive for writing? TSM has the media_type of all tapes (q libvol f=d), so I would think it should know not to do this. Thanks Rick - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message. The information contained in this transmission contains privileged and confidential information. It is intended only for the use of the person named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. CAUTION: Intended recipients should NOT use email communication for emergent or urgent health care matters.
Re: 3584 upgrade: 3592-E05 to 3592-E07
I would automate the check out process and run it before the check in process. That will keep the old tapes at the bottom of the scratch list. Provided there is enough scratch then the older tapes will not make it to the top. TSM will reuse a tape immediately if it is mounted and becomes scratch. I suspect TSM will not know the full barcode and may not be able to know which type of media. Being a read-only tape it should have an error and try another tape. Andy Huebner -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Rhodes, Richard L. Sent: Thursday, June 19, 2014 11:19 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] 3584 upgrade: 3592-E05 to 3592-E07 Hi, This weekend we are upgrading all of our tape drives (in 2 libraries) from 3592-E05 (TS1120) to 3592-E07 (TS1140). The libraries currently have a mix of JA and JB media. We will be migrating over time to all new JC media. JA tapes are READONLY on 3592-E07 drives. JB tapes are READ/WRITE on 3592-E07 drives. The plan is to: - Export out of the lib all current scratch JA/JB media. - Mark all existing JA/JB media ReadOnly. - Insert lots of new JC media. - TSM will write to the new JC tapes. - As JA/JB tapes drop to scratch, export them out of the Library, and insert more JC media. When JA/JB tapes drop to SCRATCH status, I'm not sure I will always be able to export them before TSM might try and reuse them. If TSM tries to use a JB tape, that is OK - it will work. But what if TSM selects a JA tape and tries to use it. That would fail since 3592-E07 drives can READ JA media but NOT WRITE to them. Q) Is TSM smart enough to not load a JA media into a 3592-E07 drive for writing? TSM has the media_type of all tapes (q libvol f=d), so I would think it should know not to do this. Thanks Rick - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
3584 upgrade: 3592-E05 to 3592-E07
Hi, This weekend we are upgrading all of our tape drives (in 2 libraries) from 3592-E05 (TS1120) to 3592-E07 (TS1140). The libraries currently have a mix of JA and JB media. We will be migrating over time to all new JC media. JA tapes are READONLY on 3592-E07 drives. JB tapes are READ/WRITE on 3592-E07 drives. The plan is to: - Export out of the lib all current scratch JA/JB media. - Mark all existing JA/JB media ReadOnly. - Insert lots of new JC media. - TSM will write to the new JC tapes. - As JA/JB tapes drop to scratch, export them out of the Library, and insert more JC media. When JA/JB tapes drop to SCRATCH status, I'm not sure I will always be able to export them before TSM might try and reuse them. If TSM tries to use a JB tape, that is OK - it will work. But what if TSM selects a JA tape and tries to use it. That would fail since 3592-E07 drives can READ JA media but NOT WRITE to them. Q) Is TSM smart enough to not load a JA media into a 3592-E07 drive for writing? TSM has the media_type of all tapes (q libvol f=d), so I would think it should know not to do this. Thanks Rick - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.