I got bogged down last week with other stuff, but I have PMR 50613,550,000
open now. I'll keep folks posted on developments on it.
On Wed, Jan 07, 2015 at 09:02:10AM +1100, Grant Street wrote:
> Could you post the PMR number so others can track it? Also if it becomes
> a RFE, for some reason, can you post the RFE number so that others (ie
> me) can vote for it?
>
> Even though this is functionality that I don't need now, it is something
> that may be of use and help in future architecture designs. We tend to
> use mixed generational media ie LTO4, LTO5 and LTO6 because of our
> mostly Archival nature. Being able to extend the range of media by using
> a mix of drives in a sane way, would definitely be of interest for us.
>
> Thanks
>
> Grant
>
> On 07/01/15 01:47, Skylar Thompson wrote:
> > Good to know. Unfortunately, while we have discrete barcode ranges for
> > each media type, it would be a big change for our checkin/checkout
> > procedures so I don't know that we'll be able to go that route. We'll live
> > with it for now, and file a PMR with IBM if it does start impacting us
> > more. Based on the documentation, it does seem like the current behavior is
> > a defect.
> >
> > On Fri, Dec 12, 2014 at 04:29:18PM +0000, Prather, Wanda wrote:
> >> I've never had a problem defining multiple TSM (logical) libraries on one
> >> device address (but I can't say I've tried it since 6.2, and that was on
> >> Windows).
> >>
> >> What you can't do is have one device class pointing to 2 different
> >> libraries, so you'll also have to do some juggling there, create some new
> >> devclasses and storage pools to use going forward.
> >>
> >>
> >> Wanda Prather
> >> TSM Consultant
> >> ICF International Cybersecurity Division
> >>
> >>
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
> >> Behalf Of Skylar Thompson
> >> Sent: Thursday, December 11, 2014 10:15 AM
> >> To: ADSM-L AT VM.MARIST DOT EDU
> >> Subject: Re: [ADSM-L] Drive preference in a mixed-media library sharing
> >> environment
> >>
> >> Interesting. I hadn't considered using different libraries to solve this.
> >> It was a little unclear from the thread - does this require partitioning
> >> on the library side? I wasn't aware that two different libraries
> >> (presumably with two different paths) could share a single device special
> >> node.
> >>
> >> On Wed, Dec 10, 2014 at 06:23:10PM -0600, Roger Deschner wrote:
> >>> It won't work. I tried and failed in a StorageTek SL500 library with
> >>> LTO4 and LTO5. Just like you are reporting, the LTO4 tapes would get
> >>> mounted in the LTO5 drives first, and then there was no free drive in
> >>> which to mount a LTO5 tape. I tried all kinds of tricks to make it
> >>> work, but it did not work.
> >>>
> >>> Furthermore, despite claims of compatibility, I found that there was a
> >>> much higher media error rate when using LTO4 tapes in LTO5 drives,
> >>> compared to using the same LTO4 tapes in LTO4 drives. These were HP
> >>> drives.
> >>>
> >>> The only way around it is to define two libraries in TSM, one
> >>> consisting of the LTO5 drives and tapes, and the other consisting of
> >>> the LTO6 drives and tapes. Hopefully your LTO5 and LTO6 tapes can be
> >>> identified by unique sequences of volsers, e.g. L50001 versus L60001,
> >>> which will greatly simplify TSM CHECKIN commands, because then you can
> >>> use ranges instead of specifying lists of individual volsers. To check
> >>> tapes into that mixed-media library I use something like
> >>> VOLRANGE=L50000,L59999 on the CHECKIN and LABEL commands to make sure
> >>> the right tapes get checked into the right TSM Library. Fortunately
> >>> the different generations of tape cartridges are different colors.
> >>>
> >>> You can read all about what I went through, and the good, helpful
> >>> recommendations from others on this list, by searching the ADSM-L
> >>> archives for "UN-mixing LTO-4 and LTO-5". Thanks again to Remco Post
> >>> and Wanda Prather for their help back then in 2012!
> >>>
> >>> Roger Deschner University of Illinois at Chicago rogerd AT uic
> >>> DOT edu
> >>> ======I have not lost my mind -- it is backed up on tape
> >>> somewhere.=====
> >>>
> >>>
> >>> On Wed, 10 Dec 2014, Grant Street wrote:
> >>>
> >>>> On 10/12/14 02:40, Skylar Thompson wrote:
> >>>>> Hi folks,
> >>>>>
> >>>>> We have two TSM 6.3.4.300 servers connected to a STK SL3000 with 8x
> >>>>> LTO5 drives, and 8x LTO6 drives. One of the TSM servers is the
> >>>>> library manager, and the other is a client. I'm seeing odd behavior
> >>>>> when the client requests mounts from the server. My understanding
> >>>>> is that a mount request for a volume will be placed preferentially
> >>>>> in the least-capable drive for that volume; that is, a LTO5 volume
> >>>>> mounted for write will be placed in a LTO5 drive if it's available,
> >>>>> and in a LTO6 drive if no LTO5 drives are available.
> >>>>>
> >>>>> What I'm seeing is that LTO5 volumes are ending up in LTO6 drives
> >>>>> first, even with no LTO5 drives in use at all. I've verified that
> >>>>> all the LTO5 drives and paths are online for both servers.
> >>>>>
> >>>>> I haven't played with MOUNTLIMIT yet, but I don't think it'll do
> >>>>> any good since I think that still depends on the mounts ending up
> >>>>> in the least-capable drives first.
> >>>>>
> >>>>> Any thoughts?
> >>>>>
> >>>>> --
> >>>>> -- Skylar Thompson (skylar2 AT u.washington DOT edu)
> >>>>> -- Genome Sciences Department, System Administrator
> >>>>> -- Foege Building S046, (206)-685-7354
> >>>>> -- University of Washington School of Medicine
> >>>> might be a stab in the dark ..... try numbering the drives such that
> >>>> the LTO5's are first in the drive list or vice versa.
> >>>> That way when tsm "scans" for an available drive it will always try
> >>>> the LTO5's first.
> >>>>
> >>>> HTH
> >>>>
> >>>> Grant
> >>>>
> >> --
> >> -- Skylar Thompson (skylar2 AT u.washington DOT edu)
> >> -- Genome Sciences Department, System Administrator
> >> -- Foege Building S046, (206)-685-7354
> >> -- University of Washington School of Medicine
> > --
> > -- Skylar Thompson (skylar2 AT u.washington DOT edu)
> > -- Genome Sciences Department, System Administrator
> > -- Foege Building S046, (206)-685-7354
> > -- University of Washington School of Medicine
--
-- Skylar Thompson (skylar2 AT u.washington DOT edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine
|
