LTO Tape Technologies update

[Tim Jones]

Hi Folks,

It’s been a while and with LTO-8 finally shipping in quantity, I thought I’d take a moment and refresh the LTO technologies information as to capacities, speeds, and compatibilities.

Device Interface Native Performance Native Capacity
LTO-1 SCSI, FC 15MB/Sec, 4GB/Hr 100GB
LTO-2 SCSI, FC 30MB/Sec, 108GB/Hr 200GB
LTO-3 SCSI, SAS, FC 40-80MB/Sec, 144-288GB/Hr 400GB
LTO-4 SCSI, SAS, FC 40-110MB/Sec, 144-396GB/Hr 800GB
LTO-5 SAS, F-C 40-140MB/Sec, 144-504GB/Hr 1.5TB
LTO-6 SAS, F-C 40-160MB/Sec, 144-576GB/Hr 2.5TB
LTO-7 SAS, F-C 40-300MB/sec, 144-1,080GB/Hr 6TB
LTO-8 (M8) SAS, F-C 40-300MB/sec, 144-1,080GB/Hr 9TB
LTO-8 SAS, F-C 40-300MB/sec, 144-1,080GB/Hr 12TB
(be sure to scroll horizontally to see the entire table)

While there are “Thunderbolt” and “USB-3” drives being advertised, internally these are simply SAS devices with an adapter to provide the interconnect between the TB or USB interface and the SAS tape drive.

As for compatibility between drives and media types, up through LTO-7, all drivers are capable of writing 1 generation back, and reading 2 generations back. Meaning that an LTO-6 with read and write an LTO-5 tape and READ an LTO-4 tape. However, starting with LTO-8, the drives are only capable of reading and writing one generation back (meaning that an LTO-8 drive will not READ an LTO-6 tape).

The M8 entry for the LTO-8 drive refers to an LTO-8 drive using a specially formatted LTO-7 tape. Be aware that if you do have a system that will reformat your LTO-7 tapes to the 9TB, M8 format, those tapes cannot be reformatted back to LTO-7 format.

Finally, the LTO-M8 media (specially formatted LTO-7 tapes) store 9TB on an LTO-8 drive, but current LTO.org specs do not include reading M8 formatted tapes in an LTO-9 or later drive.

At this stage, with the lack of support moving to the planned LTO-9 spec, limited device support for manually formatting your own tapes, and the lack of an incremental capacity value, we do not recommend the M8 format as you only gain 3TB/tape and the cost per GB does not balance out against native LTO-8 tapes.

Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.tolisgroup.com
BRU … because it’s the RESTORE that matters!

[Tim Gerhard]

+ LTO8 Full-Height is 360 MB/s on libraries. Was hoping IBM could do full height standalones, but they aren’t playing ball.

I also agree M8 is horrible.

Tim Gerhard
MagStor Inc.
614-505-6333
[email protected]
NAB 2018 Booth #SL15816

[Luke Mullen]

You take a speed hit with half height standalone drives? How significant?

[Tim Gerhard]

You take a speed hit on half-height standalone or HH library drives on LTO8.

LTO4 and below was a bigger drop for half-height. I think LTO5 is when it was leveling out and you wern’t getting any decrease up to LTO7s.

LTO1 even had 2x half heights with different speeds.

Tim Gerhard
MagStor Inc.
614-505-6333
[email protected]
NAB 2018 Booth #SL15816

[Tim Jones]

Not on any drives since LTO-5. The servos and positioning controls are much more exact than on the older drives, so the tapes run at full speed on both.

As others have mentioned, the full height drives are specific to a group of IT-oriented silo-style libraries. So unless you’re working with the big full rack, multi-cabinet units, there’s no use for a full height drive.

Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.tolisgroup.com
BRU … because it’s the RESTORE that matters!

[Tim Jones]

I suspect that you’re probably seeing a difference between Fiber Channel and SAS more than FH versus HH. Fiber Channel doesn’t suffer from the causes of the slow down on SAS due to TLR and buffer issues. You also won’t see the slow down with SAS if you’re using a 12Gb SAS HBA (which the Mac platform does not support – PCIe-3 x8)..

There really is no difference with the FH to HH comparison when the host environment is equal.

Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.tolisgroup.com
BRU … because it’s the RESTORE that matters!

[Neil Sadwelkar]

For the purpose of calculation (and budgeting), I normally account for the ‘overhead’, particularly for file sequence type of data.

So, my numbers are
LTO-5 – 1.3 TB
LTO-6 – 2.2 TB
LTO-7 – 5.2 TB

This is from adding files/folders in 100 GB increments, and doing ‘How many tapes’ in Bru-PE till it goes from ‘1 LTO-x tapes’ to ‘2 LTO-x tapes’.

———————————–
Neil Sadwelkar
neilsadwelkar.blogspot.com
twitter: fcpguru
FCP Editor, Edit systems consultant
Mumbai India

[Shaun Cammack]

Hi Tim,
Wondering if you could shed light on optimal config for buffer/blocksize for LTO-8? I’m using an ATTO H1280.

Many thanks,
Shaun

[Tim Jones]

Hi Shaun,

That is dependent on your environment – including the platform and data types. I assume that since you’re using the H1280 you’re running on a Windows or Linux system.

For Linux, you will run into kernel and sg settings walls. We’ve noticed that most 4.x kernels won’t allow buffering above 512K unless you know what to change in the sg/st layer and can recompile your kernel.

For Windows, it will depend on whether the software is running using the mini port drivers or the WIN32 tape API/SDK. In our tests on Windows 10 and Windows Server 2012 and newer, 512K seems to be the sweet spot – assuming that you are retrieving the data from a storage system that can deliver a sustained read rate of 500MB/sec or better.

In any case, backing up media files that are in the 50MB+ per file range will provide reasonably good throughput while backing up a non-Exchange email server will suffer from the extreme number of disk bottlenecks related to the file access overhead.

Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.tolisgroup.com
BRU … because it’s the RESTORE that matters!

[Shaun Cammack]

Hi Tim,
Rookie mistake…late night post. We are using a Mac Pro 3,1 with H1280 in one of the slower slots. We are using BRU 2.0.6 server and backing up to an Overland Storage Neos T24 LTO-8 (currently using LTO-7 tapes).

Our storage system can throughput over 1000MB/s and we are backing up mixed design and media files from a few MB to 10GB or more.

I know there is a TLR issue with the R680 card, but I guess I incorrectly assumed that the H1280 wouldn’t suffer from this?

I currently have the H1280 maximum I/O transfer size set to 4MB. In BRU, I have the LTO-8 drive block size set to 512K and the write cache at 1024MB.

We will be moving one of our Mac Pro 5,1s into the server role pretty soon…faster procs and triple the RAM, plus faster PCIe on slots 3 & 4.

Ultimately, though, is the TLR issue going to be a dealbreaker with ATTO and the Mac? If so, is there a recommended card I should purchase?