Tape drives on different busses

[hkyeakley]

I'm working on tuning some tape drives we have plugged into an Alphaserver running Tru64.

I own the Tru64 Books by Digital Press, and I'm specifically reading in the Troubleshooting book (Moore & Hancock). On page 164, they give performance tips for tape drives. Tip #1 reads:

"Don't mix disks and tapes on the same I/O bus. An even better idea, if the configuration permits, is to isolate each individual tape device on its own bus."

So, I have 12 LTO-4 Fibre channel drives connecting over a Brocade switched SAN fabric. The server in question has 8 HBAs: 4 on the A side and 4 on the B side. In this configuration, is it possible to isolate each one of my drives so that it has it's own bus?

Any tips on if/how to do that would be greatly appreciated.

- Heathe

[Steven Schweda]

I have no fibre, so I know nothing, but I
suspect that this suggestion applies more to
SCSI than to any fibre channel configuration.
How old is the book? How old is your
hardware?

Having an old, slow SCSI tape drive on the
same SCSI bus as a disk drive can make disk
I/O slower because the SCSI bus speed is
held down by the bus speed of the tape drive.

Also, data transfers between a disk drive and
a tape drive on the same bus will generally
be slower because the one bus will be busier
than separate buses (one for the disk, one
for the tape) would be.

[Martin Moore · Accepted solution]

Speaking as one of the authors... :)

Steven is exactly right. The troubleshooting book was written when Fibrechannel was in its infancy, and that performance suggestion was relevant to directly connected SCSI disks and tapes, which at that time was the prevalent type of configuration. The suggestion really isn't applicable to modern SAN configurations.

Martin

[DCBrown]

On parallel SCSI, tapes could often not disconnect on long transfers so as not to loose streaming. And if they did disconnect/reconnect then they were fighting with disks during arbitration resulting in... loss of streaming. So the guideline was to separate such traffic from the smaller/faster disk transfers on parallel scsi so as not to impact each other.

Although sometimes the same thing can happen on sans, its much less prevalent. The typical instances I recall were because of high bandwidth consumption during nightly tape backups when both the disk traffic representing the source for backups was inbound on the san AND the repackaged data was outbound to tapes... and multiple disk/tape streams were ongoing simultaneously. This routing congestion within the san resulted in lost frames/packets. No so bad for disk traffic as a retry has little consequence. But for tape where loss of tape position can result this causes big problems. Most tape backup apps upon hitting such errors close the current tape and move on. With Tru64 (forget which version) LLER as added just for the longer tape transfers. But the link level error recovery turned out to pretty much be a bust with most tapes as they waited until the end of the transfer to report the frame loss rather than when detected by which time the controllers often no longer had the frame(s) in cache to retransmit.

The other case I recall was a virtual tape box (linux server in most cases) masquarading as a tape. It only spoke loop protocol and was broadcasting some packets. Broadcasts don't abide by soft switch zoning -- or at least didn't in this case -- and flooded all the hbas with extraneous traffic. The result was something like 70% of the san bandwidth was extraneously used up.

In both of these cases, isolating tape traffic is a huge win but requires a separate san (switch(s)) and hba(s) just dedicated to tapes. But these are extreme cases.