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 AT VM.MARIST DOT EDU] On Behalf Of
Prather, Wanda
Sent: Thursday, June 19, 2014 11:51 PM
To: ADSM-L AT VM.MARIST DOT 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=nnnn
and go back to using a scratch pool again.
W
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Thomas Denier
Sent: Thursday, June 19, 2014 2:46 PM
To: ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT EDU] On Behalf Of
Rhodes, Richard L.
Sent: Thursday, June 19, 2014 12:19 PM
To: ADSM-L AT VM.MARIST DOT 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.
|
