StoreEver Tape Storage
Showing results for 
Search instead for 
Did you mean: 

Best practice for SCSI Addressing Convention for LTOs

Go to solution
Occasional Contributor

Best practice for SCSI Addressing Convention for LTOs

It has been proposed here to give all LTO drives a SCSI ID of Zero, and place each on a different channel.

Given that we are also running an XP512 with LUNS shared down channels, how would this standard affect what we do? I can imagine there are limits of the number of SCSI Channels seen by HP-UX, and the bandwidth limit of SCSI, the number of bridges, etc.

Any sagely advice out there?

Thanks, Ian Dennison
Building a dumber user
Trusted Contributor

Re: Best practice for SCSI Addressing Convention for LTOs

It is indeed being suggested that you use a separate SCSI HBA for each LTO drive due to the bandwidth required by each drive to keep it streaming. They will transfer data at 80MB/s burst rate (SCSI transfer) and an effective transfer rate of 30MB/s (assuming average 2:1 compression). Having more than one drive per bus increases the risk that drives fall out of streaming, which really hurts your performance.

Similiary, if you use a library with FC-to-SCSI bridges, each LTO drive should be on a dedicated SCSI channel on the bridge.

If you use 1GB FC infrastructure, not more than 2 drives should be on any FC link, as again you may introduce bandwidth bottlenecks.

As to SCSI ID 0, as each drive should have a dedicate bus, which ID you use for the drive should be irrelevant (only seen within the scope of that bus).

While there are some limits as to how many HBAs can be managed and/or seen by HP-UX, these limits are quite astronomical for the average data center server and you should not have to worry about it. The number of individual LUNs on a single server can exceed the 10s of thousands before you run into limitations of the kernel (kernel reconfiugation assumed).

There are more specific documents on performance suggestions for LTO drives. I'm going to try to find some and post the URLs later.