- Community Home
- >
- Servers and Operating Systems
- >
- Legacy
- >
- Operating System - Tru64 Unix
- >
- Tape drives on different busses
Operating System - Tru64 Unix
1752291
Members
4391
Online
108786
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Go to solution
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-10-2010 09:41 AM
тАО02-10-2010 09:41 AM
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
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
Solved! Go to Solution.
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-10-2010 01:02 PM
тАО02-10-2010 01:02 PM
Re: Tape drives on different busses
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-10-2010 01:11 PM
тАО02-10-2010 01:11 PM
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
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
I work for HPE
A quick resolution to technical issues for your HPE products is just a click away HPE Support Center
See Self Help Post for more details
A quick resolution to technical issues for your HPE products is just a click away HPE Support Center
See Self Help Post for more details
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-20-2010 12:56 PM
тАО02-20-2010 12:56 PM
Re: Tape drives on different busses
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.
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.
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP