Hi,
I have 5 questions here about pickers and how they might affect the
speed of the tape drives in the library. Sorry to ask so much, but I
didn't see any easy way to break down these questions as separate
postings as they're all pretty much related to each other.
I always thought that slow devices should always be placed last on a
SCSI chain. In other words, any device on the chain will run no faster
than the previous device, so it would not make sense to place a fast
device after a slower one. Devices should be placed in order from
fastest to slowest, and if done this way, every device will run at its
proper speed, assuming good cable, length, etc. but not sure if this
logic applies to pickers, so here are my questions:
1. In a typical LVD tape library, will having the picker first on the
same bus as the tape drives slow down the drives?
Part of me wants to say yes because the picker is slower than the
drives, but then again, it's not a drive itself so maybe the system
ignores the fact that it's a picker, and its presence on the chain does
not inhibit the drives? The reason I ask is because we have an ATL P1000
tape library with 2 SDLT drives (LVD). On the library, the picker shares
the same bus with these drives, but the picker comes first on the chain,
and the last drive is terminated. The SCSI ids are:
picker=0
drive1=2
drive2=3
One LVD SCSI cable connects the whole enchilada to the host. We've never
had any problems, but I'm wondering if we're suffering speed loss as a
result of having the picker sharing the bus with the drives? Like maybe
the drives are falling back to the speed of the picker or something?
Could that happen? Certainly, performance could be increased by having
the drives on separate buses, but curious about whether the picker would
affect their speed, too.
I see the following during boot up (we're running Linux RedHat):
Slot Ch ID LUN Vendor Product Size Sync Bus
------------------------------------------------------------
06 A 0 0 STK L80 ASYN 8
06 A 2 0 SEAGATE ULTRIUM06242-XXX 80.0 16
06 A 3 0 SEAGATE ULTRIUM06242-XXX 80.0 16
06 B 4 0 SEAGATE ULTRIUM06242-XXX 80.0 16
06 B 5 0 SEAGATE ULTRIUM06242-XXX 80.0 16
05 A 0 0 ATL 6220050 ASYN 16
05 A 2 0 Quantum Super DLT1 80.0 16
05 A 3 0 Quantum Super DLT1 80.0 16
2. What do the terms: 'Sync' and 'Bus' refer to?
3. Notice in the above output that the 'Bus' value on the Storagetek is
8, but the drives are 16. Unlike the ATL library, they do not match. Not
sure what this implies, but if it has to do with speed then this has me
a little concerned that maybe the STK picker might be forcing the LTO
drives 1-2 (SCSI ID 2-3) to maybe lower their speed since it shares the
same bus as drives ULTRIUM drives 1-2 and comes first on the bus?
4. Some people suggest placing the picker on its own bus so in the event
that one or more drives die and bring the affected bus down, the picker
will not be subsequently affected. That's a good thing if you want to
guarantee that the picker will continue to function if a drive dies or
something weird happens on the bus that that the affected drive(s) was
on. Seems it would be prudent, therefore, assuming you had a spare
channel on the host adapter card, to put the picker on its own bus, BUT
what I would like to know is this: Are there any arguments to suggest
other reasons for doing this? People say picker generates little
traffic, so maybe no need, but curious about why you'd put it on its own
bus? Guess this gets back to my first question.
5. Does it really matter what the SCSI id of the picker is as long as it
doesn't duplicate another ID on the same bus or one that's reserved?
I noticed on our two ATL libraries, the picker is ALWAYS id 0, the
picker is always first on the bus, and the drives follow at like IDs 2,
3 and 4. That's how they were set up originally. We didn't set them up
this way, but they run like clock work. HOWEVER, on our Storagetek
library, the picker was id 6 and came last on the first bus with drives
1-2 being first. Drives 1-2 had SCSI ids 2 and 3 respectively. Drives
3-4 shared the second bus at ids 4 and 5. We had nothing but headaches.
We then changed the SCSI id of the picker to 0 and placed it first on
the bus with drives 1-2 last on this same bus. Drives 3-4 remained on
the second bus as before. We now notice that several things that were
not working before are now working. For example, prior, if we wiped out
the jukebox configuration, recreated and then inventoried a previously
bar coded tape, NetWorker would always insist on loading the tape that
first time, even with bar code reader enabled. Our ATL libraries never
had to load the tape, even the first time, following a jukebox
recreation as long as bar code reader was enabled. After making the
changes on the STK, we now notice that previously bar coded tapes
inventory the first time, following the jukebox recreation, without
having to load the tapes. This saves a lotta time!!!! Gotta wonder about
the change. It did something good!
Would greatly appreciate any feedback on these questions.
George
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
