Talk:Linear Tape-Open

Reference 46?

I tried to follow reference 46, but the web site requested a password. Is there an open version of these specs available? —Preceding unsigned comment added by 24.128.26.49 (talk) 14:17, 21 March 2011 (UTC)

Capacity figures

All capacity figures are assumed to be native capacity, uncompressed. It doesn't make sense to compare compressed figures. What is really getting stored on tape is just plain data. Just because it is the output of a compression algorithm, doesn't mean anything. Compressed figures have no place in the stat sheet. So we have no need to say redundant things like "Native Uncompressed Capacity." The statement is redundant.

Yes, I hate compressed figures. Yes, this is a rant. Yes, I care. Austin Murphy 19:24, 24 July 2006 (UTC)

I agree that native capacity must be stated. However, I disagree that compression statistics are useless. It represents a theoretical upper limit on the capacity of a tape. The compression radio itself is part of the tape drive spec, taking into account memory and algorithm changes. Having said that, I have at least one LTO6 tape that claims to have 7.1T on it, although the compressed max size is 6T, so even as a max, it has to be taken with a grain of salt. But I regularly get actual capacities of compressed tapes almost exactly between the native size and the "max" compressed size. --ssd (talk) 18:23, 1 December 2016 (UTC)

I hate them too, but they seem to be part of the system. They are not max, though, but typical for someone's version of typical data. With very non-random data, it will go much higher. Gah4 (talk) 20:51, 4 September 2018 (UTC)

"Compressed capacity" is pure marketing and bears little-to-no relationship to what most users see. Real world figures on my site are around 1.1-1.2:1. If I use repetitive text or other low-entropy data (database dumps are a good source) then I've hit 8:1 on a purely experimental basis in LTO5 - but this is an exception. We've seen _NO_ difference in real world compression ratio across the generations even as compression algorithms have supposedly improved (In reality the majority of what little gain has actually been achieved comes from ingesting larger raw chunks of data)Stoatwblr (talk) 00:31, 10 November 2020 (UTC)

I would completely remove "compressed capacity", at least from the comparison tables in the article. Assuming it to be 2.5:1 is completely arbitrary. In reality it is neither a lower, nor an upper bound for actual compressed capacity. Kwinzman (talk) 09:32, 25 April 2021 (UTC)

Colours

Are the colours actually part of the standard or just the colours used by a particular manufacturer? All the HP brand 400GB LTO media I have seen was coloured dark red, which doesn't match the table in the article. --James 03:37, 18 October 2005 (UTC)

I have used HP LTO-1 (100GB/200GB) tapes, they're coloured blue.

All the LTO-2 cartridges that I have seen have been purple. I've seen Fuji, Maxell, TDK, HP, and Overland.

My cleaning cartridges are Black and are universal (across HP LTO-1 and LTO-2 drives at least).

I don't think any of the LTO5/6 colors are standardized except that the WORM tapes are bi-colored. --ssd (talk) 20:25, 1 December 2016 (UTC)

WORM

Q: What does write-once, read-many mean in this context? Are the non-WORM varieties of tape only readable once? Or is it possible to write to them more than once?

A: It means you can write to the tape once, read it as often as you like, BUT you can't erase the tape or overwrite it. The idea is to keep some data indefinitely to meet regulatory requirements or for some other purpose. The regular varities of tape can be written and read until they wear out.

Recording characteristics

I've been googling this and the main page here is about all the info I can find!

Some of the questions I would have are:

What's the logical inter block gap (eg DDS is 4bytes, QIC is more like 2kbytes

Q: How does it react to already compressed data? (again DDS eg: logical capacity drops to about 60% if you don't physicall turn off the compression!)

A: For each data block written to tape with compression on it compares the size of the compressed and uncompressed data and writes whichever is smaller. Each block has one bit to indicate compressed or not. You can also turn off compression through a SCSI command. (Linux mt will do it.)

Q: I have found a couple of hits that the streaming requirements are easier than other tape drives, do the tape drives run at multiple speeds?

A: The HP LTO-2 Drive I use can stream at 10MB/sec to 30MB/sec. Other drives have different streaming ranges.

Later... Okay, I've put the stuff I did find eventually in the article looks like chop. chop time. 86.16.135.53 08:22, 26 March 2006 (UTC)

Units used for capacity and transfer speeds

Multiple-byte units
Decimal Value Metric 1000 kB kilobyte 10002 MB megabyte 10003 GB gigabyte 10004 TB terabyte 10005 PB petabyte 10006 EB exabyte 10007 ZB zettabyte 10008 YB yottabyte 10009 RB ronnabyte 100010 QB quettabyte	Binary Value IEC Memory 1024 KiB kibibyte KB kilobyte 10242 MiB mebibyte MB megabyte 10243 GiB gibibyte GB gigabyte 10244 TiB tebibyte TB terabyte 10245 PiB pebibyte — 10246 EiB exbibyte — 10247 ZiB zebibyte — 10248 YiB yobibyte — — —
Orders of magnitude of data

As the pages for binary units, gigabyte, etc. makes very clear, there is more than one interpretation for "GB". I'm not trying to start YAUW (Yet Another Unit War) but I do think we have to either:

• Use MiB/s and GiB as these units aren't ambiguous

or:

• Add an explanation (perhaps in the notes section) stating that the units for this page is 2^x or 1024^y

Doldr 16:05, 6 September 2006 (UTC)

That (the addition of the unit defs) made sure that people know what we mean. Now we just have to figure out which is correct for LTO... Information about this isn't exactly easy to find (maybe someone is sitting on detailed info?). The few clues I've found seem to indicate that (like hard drives and DVDs) LTO uses 10^9, not 2^30. This is what I've found:

• the roadmap states, 400G, 800G, 1.6T, etc. this transition from G->T is only true for 10-base.
• "The LTO-3 U316-400 specification (re)defines 1 Gb as 1,000,000,000" from page 6 of http://www.bakbone.com/docs/App_Notes_CertanceCL800_A7-1.pdf#search=%22LTO3%20capacity%201024%22

-- Doldr 15:32, 7 September 2006 (UTC)

Not finding any conclusive information about this I turned to "experiments". With compression off I let dd fill up two different tapes (using one of our IBM LTO3 drives). Here are the results:

• HP LTO2 tape: 212149993472 Bytes (197.6 GiB or 212.1 GB)
• IBM LTO3 tape: 423524040704 Bytes (394.4 GiB or 423.5 GB)

My conclusion, LTO tapes as hard drives and DVDs are spec'ed in GB (10^9). In reality tapes are manufactured to be atleast that capacity (with some margin it seems). -- Doldr 12:19, 8 September 2006 (UTC)

Interesting experiment. What was the block size for dd? It appears that neither unit system precisely describes the capacity in round numbers. 200 GB == 186 GiB, and 200 GiB == 214 GB; double that for LTO-3. Is it possible that there are error sections that are unused? I wonder if the streaming speed had anything to do with it. -- Austin Murphy 18:13, 8 September 2006 (UTC)

The template of byte quantities is pretty cool. maybe we can use it. -- Austin Murphy 18:34, 8 September 2006 (UTC)

I used 1 MiB blocksize with dd and the streaming speed was close to peak (76 MiB/s for the LTO3 and a bit under half that for LTO2). I think we should try to "get to the spec", maybe ask IBM or lto.org in some way. Doldr 09:51, 11 September 2006 (UTC)

Check out this page: ECMA 319, it looks like 100 Gbytes, the units used in the docs, means 100 x 10⁹ bytes. -- Austin Murphy 21:17, 23 September 2006 (UTC)

Backward Compatibility

The table in the "Generations" section currently lists LTO-4 as reading only LTO-3 and LTO-4 tapes, and writing only LTO-4. This would seem to conflict with the LTO Consortium's published information, which says that any LTO drive is required to read tapes of its own generation and at least the two preceding it (so LTO-2, -3 and -4 for LTO-4 drives), and write to tapes of its own and at least the immediate preceding generation (so both LTO-3 and LTO-4 tapes for LTO-4 drives). I realise that LTO-4 has yet to be finalised, but is there any reason to expect that the prior policy on backward compatibility will change? -- 210.54.3.3 07:13, 22 November 2006 (UTC)

I would prefer to delete those two rows from the table since they describe something other than that specific generation of LTO in that column. The rows ("Reading" and "Writing") describe interoperability between generations and do a poor job of it. The previous section describes it suitably anyway. -- Austin Murphy 22:27, 26 November 2006 (UTC)

I deleted those rows. -- Austin Murphy 15:28, 27 November 2006 (UTC)

MAJOR LTO CHANGES at LTO7 onwards - see https://www.lto.org/lto-generation-compatibility/

Up to LTO6, LTO drives could RW the generation before and RO 2 generations back - ie, LTO6, could RW LTO5 and RO LTO4 - this satisfies LTO consortium requirements - and NOBODY bothered with being able to read 3 generations back (I believe the OP misread the LTO consortium's intent in that statement)

LTO7 drives (HP and IBM) cannot load LTO6 or LTO5 media. This is because MP tape is more abrasive than BaFe and will quickly destroy heads formulated for BaFe (IE: NO backwards compatibility! - and this is contrary to what is in the official statement). There was originally an intention to be backwards compatible with LTO6 BaFe, but as there's no way of reliably telling from the MAM if a LTO6 tape is MP or BaFE the idea was dropped

From LTO8 onwards, backwards compatibility is only ONE generation

It's likely that this issue will recur when moving from BaFe to SrFe

Stoatwblr (talk) 00:57, 10 November 2020 (UTC)

Tape wear

Am I reading this article correctly w/respect to the number of passes over the tape required to fill a tape to capacity? It sounds as if an LTO-1 drive requires 48 end-to-end passes, while an LTO-2 drive requires 64 passes. What are the implications to tape wear and head wear? How does this compare to helical-scan tape formats? -- dpotter 23:52, 5 February 2007 (UTC)

You are reading it correctly. X total tracks / Y tracks per pass (head elements) = Z total passes. 512/8=64. In this configuration the head is essentially fixed while in a helical scan configuration the head is rapidly rotating against the tape. A helical scan configuration will only make one pass over the tape. Both cause more tape wear than one with knowledge of audio tapes might expect. I don't know which causes more wear. As an aside, I've heard that older rented VHS tapes frequently have a loss of signal at certain particular points on the tape. This is due to the pause function keeping the spinning tape head at the same spot on the tape, slowly wearing away the magnetic coating. You don't get this with linear tape systems, because "pause" is not even possible. Shoe-shining is a problem with high-speed linear serpentine tapes. If a drive is shoe-shining, then it is effectively making many more passes than normal. -- Austin Murphy 19:13, 6 February 2007 (UTC)

Shoe shining is a very real problem which LTO goes to some trouble to avoid.

To try and prevent it happening - if the input buffer is starving, LTO drives will step their linear speed down to as little as 10% of full speed (earlier ones would only step to 30%, but that's 10-20MB/s for LTO1-2). Drives don't start until the buffer has reached a threshold level (or start at lowest speed), specifically in order to assess fill speed and select an appropriate starting linear speed to keep the buffer in a healthy state

In other words - if you hear shoe shining on a LTO drive, you almost always have a serious problem. It's usually a bad head or tape causing verify-after-write failure and the drive is repositioning to rewrite data Stoatwblr (talk) 01:08, 10 November 2020 (UTC)

HH (Half-height) drives

I feel half-height drives should be mentioned for LTO-2 & LTO-3 (and very soon LTO4). Perhaps only a short excerpt about how they operate at ~3/4 the data transfer rate of their full-height counterparts but take up only half the size height-wise? Being that they still use the same media as they are named after, capacity of course does not change. -- halfmoon 01:48, 31 August 2007 (UTC)

Dells HH LTO-4 Tape Drive does have same data transfer speeds as it's full height sibling! [ http://www.dell.com/downloads/global/products/pvaul/en/tbu_drives_comp.pdf ] —Preceding unsigned comment added by 212.254.33.106 (talk) 13:57, 14 April 2010 (UTC)

Agreed with this. I've been troubleshooting an issue and using the excellent page as reference. I discovered the HH issue yesterday and have wasted a lot of time!! Had the HH info been there I wouldn't have. I'll be updating the page again now to at least point out this discrepancy. I've read 70% of FH throughput for HH drives but I need a good source to cite before I can add that fact. Notverynick (talk) 13:37, 4 September 2013 (UTC) notverynick

Fair use rationale for Image:Lto-logo.png

Image:Lto-logo.png is being used on this article. I notice the image page specifies that the image is being used under fair use but there is no explanation or rationale as to why its use in this Wikipedia article constitutes fair use. In addition to the boilerplate fair use template, you must also write out on the image description page a specific explanation or rationale for why using this image in each article is consistent with fair use.

Please go to the image description page and edit it to include a fair use rationale. Using one of the templates at Wikipedia:Fair use rationale guideline is an easy way to insure that your image is in compliance with Wikipedia policy, but remember that you must complete the template. Do not simply insert a blank template on an image page.

If there is other fair use media, consider checking that you have specified the fair use rationale on the other images used on this page. Note that any fair use images lacking such an explanation can be deleted one week after being tagged, as described on criteria for speedy deletion. If you have any questions please ask them at the Media copyright questions page. Thank you.

BetacommandBot (talk) 20:13, 2 January 2008 (UTC)

GA Review

This review is transcluded from Talk:Linear Tape-Open/GA1. The edit link for this section can be used to add comments to the review.

This article does not meet the good article criteria and has too many issues. It has therefore failed its nomination. Issues include but are not limited to:

• Needs more references per WP:CITE
  • "Form factors" has no references
  • Most of "Technical features" has none

That's about half of the article.

Questions and comments placed on this page will receive responses. Once these issues have been resolved, feel free to renominate the article. Thanks! Gary King (talk) 06:29, 11 January 2009 (UTC)

SCSI

I noticed that all Ultrium/LTO devices on the market appear to be SCSI-only. Is there something in the specification that requires only SCSI devices? -Rolypolyman (talk) 06:17, 5 April 2009 (UTC)

"IBM called their cartridge 3480 and DEC originally called theirs CompacTape, but later it was renamed DLT and sold to Quantum." 

Excuse me, this is ambiguous. Which "it" was renamed and sold, DEC's or IBM's? Or were they the same thing? Were their specs different? Did they co-operate on the format? Can you put a link to the hacker's dictionary definition for 'squaretape'? —Preceding unsigned comment added by 38.105.85.100 (talk) 16:10, 26 January 2010 (UTC)

I think the 'History' comment is wrong. Both DLT and 3480 came out in 1984. DLT was 'low performance' and relatively cheap, and not available as channel attach. The 3480 technology was (I think) fundamentally different, and not even a competing standard as it was mainframe rather than micro/super micro. — Preceding unsigned comment added by 144.191.148.3 (talk) 15:10, 16 June 2012 (UTC)

I agree that 3480 and DLT are completely incompatible and serve different markets, but they both have linear, multi-track, half-inch tape in a square-ish cartridge. It is mentioned because LTO was built using IBM's technology (3480 & successors) and was aimed at DLT. --Austin Murphy (talk) 19:13, 25 June 2012 (UTC)

SCSI is a standardised command structure and LTO/Ultrium is intended for Enterprise-scale deployments. Other interface "standards" are either electrically odd or "orphaned" and it drives manufacturing costs up to cater to all the variations in what is really a fairly small sales market, so it makes sense to standardise (plus most of them aren't fast enough to keep up with data flow, only allow point-to-point connections or are limited to very short cable lengths. This includes ATAPI(IDE) and its SATA cousin which are essentially SOHO/SMB standards for use in a desktop system - which is one environment Linear tape drives will not survive long due to dust ingestion). FC and SAS are both highly standardised scsi transport encapsulations so there's no translation issue incurred talking to drives across these technologies. You're going to be spending several thousand dollars on a LTO drive and tapes, so why would you quibble on a couple of hundred for a decently fast HBA interface and making sure your expensive drive (plus your critical data) is treated carefully? Stoatwblr (talk) 01:26, 10 November 2020 (UTC)

Data transfer rates

"The units for data transfer generally follow the binary prefix convention. (eg. mega = 2^20)"

Is there any reliable source for that? Data transfer rates hardly ever are given in binary prefixes. --GlaMax (talk) 13:43, 27 April 2010 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to 3 external links on Linear Tape-Open. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive https://web.archive.org/20110928152753/http://www.fujifilm.com/products/storage/lineup/ltoultrium/img/pic_02.jpg to http://www.fujifilm.com/products/storage/lineup/ltoultrium/img/pic_02.jpg
• Attempted to fix sourcing for http://www.freemanreports.com/
• Added archive https://web.archive.org/20070517134748/http://www.lto.org:80/News/press.php? to http://lto.org/News/press.php

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 13:10, 8 January 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on Linear Tape-Open. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive http://web.archive.org/web/20090921143513/http://www1.ap.dell.com:80/content/products/productdetails.aspx/pvaul_110tlto3?~tab=specstab to http://www1.ap.dell.com/content/products/productdetails.aspx/pvaul_110tlto3?~tab=specstab

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 18:02, 28 February 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 11 external links on Linear Tape-Open. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20061113034635/http://www.ultrium.com/newsite/html/news_11_04_97.html to http://www.ultrium.com/newsite/html/news_11_04_97.html
• Added {{dead link}} tag to http://lto.org/pdf/011105_one_million_milestone.pdf
• Added archive https://web.archive.org/web/20110626043041/http://lto-technology.com/technology/generations.html to http://www.lto-technology.com/technology/generations.html
• Added archive https://web.archive.org/web/20110626043041/http://lto-technology.com/technology/generations.html to http://www.lto-technology.com/technology/generations.html
• Added {{dead link}} tag to http://public.dhe.ibm.com/common/ssi/ecm/en/tsw03182usen/TSW03182USEN.PDF
• Added {{dead link}} tag to http://downloads.quantum.com/lto5/6-66786-01_RevA.pdf
• Added {{dead link}} tag to http://support2.imation.com/downloads/imn/LTO/Usage_Life_Imation_Media.pdf
• Added {{dead link}} tag to http://www.ccidistribution.co.uk/datasheets/2010/apr/LTO.pdf
• Added archive https://web.archive.org/web/20120306224356/http://www.lto.org/technology/primer3.html to http://www.lto.org/technology/primer3.html
• Added archive https://web.archive.org/web/20110727053144/http://www.lto.org/News/LTO_NewsBytes/NewsBytes_June_2011.pdf to http://www.lto.org/News/LTO_NewsBytes/NewsBytes_June_2011.pdf
• Added archive https://web.archive.org/web/20060313051612/http://researchweb.watson.ibm.com/journal/rd/426/slattery.html to http://researchweb.watson.ibm.com/journal/rd/426/slattery.html
• Added archive https://web.archive.org/web/20131112162319/http://h20195.www2.hp.com/V2/getdocument.aspx?docname=4AA1-4878ENW.pdf to http://h20195.www2.hp.com/V2/getdocument.aspx?docname=4AA1-4878ENW.pdf
• Added {{dead link}} tag to http://lto.org/pdf/980803.pdf
• Added {{dead link}} tag to http://lto.org/pdf/981021.pdf
• Added archive https://web.archive.org/web/20110716113514/http://www.span.com/span_image.php?im=images/products/b/bmuth5w.jpg&sitext=&nw=389&nh=228 to http://www.span.com/span_image.php?im=images/products/b/bmuth5w.jpg&sitext=&nw=389&nh=228
• Added archive https://web.archive.org/web/20130305004420/http://www.maxell-usa.com/index.aspx?id=2;108;628;0 to http://www.maxell-usa.com/index.aspx?id=2;108;628;0
• Added archive https://web.archive.org/web/20061113034424/http://www.ultrium.com/newsite/html/licensing_certified.html to http://www.ultrium.com/newsite/html/licensing_certified.html
• Added archive https://web.archive.org/web/20120219133950/http://www.sundds-lto.com/uploadLinks/LTO%20cleaning%20white%20paper_rev3.1.pdf to http://www.sundds-lto.com/uploadLinks/LTO%20cleaning%20white%20paper_rev3.1.pdf

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 08:00, 11 November 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 6 external links on Linear Tape-Open. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Corrected formatting/usage for http://support2.imation.com/downloads/imn/LTO/Usage_Life_Imation_Media.pdf
• Added archive https://web.archive.org/web/20120926174231/http://support.dell.com/support/edocs/stor-sys/matrix/PVMatrix/lto3_400.jpg to http://support.dell.com/support/edocs/stor-sys/matrix/PVMatrix/lto3_400.jpg
• Corrected formatting/usage for http://www.span.com/span_image.php?im=images%2Fproducts%2Fb%2Fbmuth5w.jpg&sitext=&nw=389&nh=228
• Corrected formatting/usage for http://www.maxell-usa.com/index.aspx?id=2%3B108%3B628%3B0
• Corrected formatting/usage for http://lto.org/News/press.php
• Added archive https://web.archive.org/web/20160108131038/http://findarticles.com/p/articles/mi_m0EIN/is_/ai_55898372 to http://findarticles.com/p/articles/mi_m0EIN/is_/ai_55898372

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 10:00, 16 May 2017 (UTC)

band fill order

One paragraph says that band 0 is fill first, then next that bands are filled in 3, 1, 0, 2 order, suggesting 3 is first. Which one is it? Gah4 (talk) 20:57, 4 September 2018 (UTC)

Data is stored in multiple bands, but each band is composed of a number of serpentine wraps. The bands are numbered across the face of the tape for human convenience but accessed in an alternate pattern to avoid substrate stretching/wear potentially caused by accessing the bands in linear order (it's a bit more complicated than that - it's also about ensuring that if people do things like consistently only recording half a tape, that the wear is spread more evenly across the tape face rather than being concentrated on one side or other of that face - bear in mind that the heads themselves move up and down the tape to access these bands. They're not fixed in position like audio tape heads are Stoatwblr (talk) 01:34, 10 November 2020 (UTC)

read backwards

There is discussion for a different article on tape drives' ability to read backwards. It was usual for 9-track drives, and some sort algorithms are designed to use this ability. I don't see anything here about that, though given IBM's connection to LTO, I might expect it. Though I do understand that the multiple pass system means that you never have to rewind very far, and in the best case, not at all. Gah4 (talk) 23:55, 6 January 2019 (UTC)

I can't imagine it being useful. When you're reading (or writing, for that matter) LTO you don't know which "wrap" you're in, let alone where you are within the wrap. So a program would have no way of knowing whether read backwards would be time-effective. Besides, "read backwards" was invented specifically to improve performance of tape sorts, but tape sorts haven't been important since hard drives and e.g. indexed databases became practical. Jeh (talk) 01:22, 7 January 2019 (UTC)

Digital storage is organized in sectors, headed by a syncword, followed by a header and the user data. Reading the sequence backwards would imply a bit and word sync from the end of user data while its structure is unknown. This is virtually impossible (without buffering an entire, lengthy signal sequence and analyzing it in the usual read direction). Also, the media code may not be read in reverse either. Is there a point to this idea?

LTO tape is read/written in both directions in a serpentine pattern, but each wrap has its own direction that you cannot reverse – a bit like auto-reverse audio tape (which, as an analogue signal, is easily reversible). --Zac67 (talk) 07:19, 7 January 2019 (UTC)

I don't believe that tape sorts went away entirely until somewhat recently, as data larger than the available DASD has always been around. One does have to be careful with access patterns to keep disk as fast as streaming tape. But yes, read backwards was important in the days when tape buffers were expensive, and allowed for sorting large data sets on smaller computers. Yet data sets continue to increase in size, ahead of increases in computer main memory size. From IBM references, it seems that 3480 and 3490 can read backwards if the data isn't compressed. If it is compressed, the block will be read, uncompressed, and used appropriately, and transparently to the user. I might have expected IBM to keep it within LTO-1, if reasonably possible. I suspect with more advanced coding, it would get harder and harder to do. I don't know the coding method of LTO-1 close enough to know. Gah4 (talk) 22:35, 7 January 2019 (UTC)

Failure due to environmental dust

LTO (and its predecessor DLT) has a severely flawed design problem that the tape path involves near micron precision alignment of the tape to the head mechanism, and yet the LTO drive hardware has zero protection from environmental dust, no air filtration, and by design most tape libraries and standalone drives will suck unfiltered room air directly through the drive tape path.

If you want an LTO drive to last more than a few years, it is mandatory that it be operated in a virtually dust-free environment, similar to how the interior of mechanical hard drive is protected from even the smallest of dust particles like cigarette smoke.

The only way that I can see to achieve this with most LTO tape libraries is with a sealed dust tight rack enclosure that is equipped with an internal HEPA filter and circulation blower to scavenge any dust that might enter when servicing the equipment, plus also an air-to-air heat exchanger and desiccant, and/or air conditioner to prevent overheating and to keep humidity low.

Running a typical LTO tape library or standalone tape drive in the same room as an office crosscut shredder will kill it after only a year or two, due to the paper particulates getting into the drive mechanism and fouling the tapes and drive heads. Dust exposure is very expensive problem when talking about the newest high capacity tape media and drives.

It is mysterious to me why mandatory dust protection requirements would be overlooked as part of the LTO design specification. -- DMahalko (talk) 17:29, 18 November 2019 (UTC)

That may be your experience, yet others have may have experienced LTO as a rather robust medium. Experiences differ and without reliable source, all these opinions are original research. --Zac67 (talk) 17:32, 18 November 2019 (UTC)

Experience at our site is that the _TYPE_ of dust matters (We're a UK-based Russell Group university science lab)

This is backed up by discussion with Quantum, Overland, HP, IBM and Mountain Tapes - none of whom will release official statements but confirmed our findings (particularly with regard to LTO5 tapes, see below)

Geological dust - ie: brick and plaster dust from drilling - is extremely abrasive and if any sub-10 micron particles are drawn into the drive they will destroy individual head coils.

Biological dust (human skin) is soft enough that it poses no threat.

Paper dust may be damaging depending on fibre lengths but is more a problem in the gear mechanisms

Toner dust (plastic or carbon) is destructive too

It's worth noting that any dust needs to be fine enough to be carried by air currents and that means sub 10-micron. Larger particles are unlikely to get into a drive unless the environment is _very_dusty. MOH hardness matters, but a lot of dust is "flung off" a high speed tape in transit and the wrap geometry offers some protection to the heads (tapes are moving in excess of 10 metres per second, this helps a lot)

ISSUES WITH DUST:

Because of the "verify-after write, rewrite on the fly if failed" nature of LTO, data loss due to a damaged head is normally detected and corrected in flight.

What this means is that the normal manifestation of head coil damage is that tape capacity appears to decrease - and unless people are reading LTO MAM chips they generally will not see it until the damage is severe (MAM reports uncompressed data on tape vs uncompresses data remaining. If A+B is substantially less than the uncompressed tape capacity you know a lot of rewriting has been going on)

HP and IBM tape drive reporting tools use undocumented commands to get health reports of each coil in the head (read and write sets) and sending those reports back to base (if you have a support contract) will result in them telling you how badly damaged or stained your heads are.

Reading LTO MAM

Most folks don't read MAMs - we only got into this due to a few incidents relating to building work putting abrasive dust into the air and the discovery that using Maxell LTO5 media has a 6-12% chance of destroying drives due to at least one of their preformatting machines having a bad servo track(*)

MAMs can be read with a standalone reader, or using a version of sg3_utils recent enough to include sg_read_attr. I wrote a couple of support scripts for this and submitted them to the maintainer in 2018 (it can also be done using sg_raw but is more difficult to achieve)

(*)this is why Maxell exited the market - maxell media is/was OEMed in HP tapes amongst others.

HP policy is to replace Maxell-pancake LTO5 tapes without question - 800 tapes in our case. NB: HP LTO5 may be Sony, TDK or Maxell but anything purchased after 2017 is unlikely to be affected

You need to read the MAM to verify the tape media maker - the tape pancake is separately identified and serial numbered to the tape cartridge - or make an educated guess based on tape serial numbers

- Mountain Tapes (www.mptapes.com) make the only standalone LTO MAM readers in the world - all other sellers are badge engineered

TL;DR:

After 16 years of operating LTO across various generations - Yes, dust DOES matter.

If you have building work going on including anything to do with plaster wallboards, stop the drives and wait 24 hours (this is the voice of bitter experience, having had to pay for drive repairs). Drives operated in a low-dust environment show longer lives and lower degradation rates. You don't need to be fanatical about it but avoid operating in areas with paper dust (around shredders) and around people.

As for why dust precautions aren't a bigger design issue: This is enterprise media intended for enterprise environments.

The developer consortium were (and are) mostly interested in putting the things in robots and robots generally live in server rooms, _not_ SOHO/SMB offices

Robot makers - Quantum, Tandberg-Overland - etc all maintain drives without question during their contracted support period regardless of why the heads might have failed and the tapes themselves have a "limited lifetime warranty" - they may question the environment if they see excessive head failures (as Quantum did with our issues before tracing it to the Maxell LTO5 media in HP cartridges) but they won't refuse to replace failed drives unless there are signs of external damage

Tape cleaning:

Tapes with embedded dust CAN be cleaned but there's only one maker of cleaners (mptapes.com) and the cleaners cost as much as a LTO drive (~$6000) due to the inclusion of a very large high precision sapphire blade in place of the RW/head. Considering the swarf we (and others) have seen come off brand new tapes, one of these devices is worth having if you have hundreds of tapes or multiple LTO drives. At least one library vendor precleans every one of their own-brand tapes before shipment using library-mounted versions of these cleaners

Stoatwblr (talk) 23:23, 9 November 2020 (UTC)

Yes, dust does matter. Above, I was replying to the "severly flawed" design which I don't think it is. Obviously, any kind of quickly moving surface contact is somewhat vulnerable to dust, especially abrasive one. It's kind of apparent that you need to protect delicate equipment from dust – a tape drive is usually located in a computer room or data center which is at least somewhat protected against dirt and dust. We're actually having some problems with paper dust on one location, but the LTO-5 is still happily churning away after some nine years and 1.5 PB overall (the robot has required a few repairs, non dust-related, but the drive itself hasn't).

The main point being: if anything is to be added to the article in regard of a special dust (in)sensitivity, it needs to be well sourced. Otherwise, the standard practices for computer equipment should apply. --Zac67 (talk) 17:37, 10 November 2020 (UTC)

Stoatwblr That sounds like extremely useful information about LTO, but you need to publish it elsewhere before it can potentially be referenced in the article. Maybe you can approach a university researcher about your experience with tapes so they can publish a paper on it? Or contact a journalist that writes about storage solution with your reliability experience. See original research. Kwinzman (talk) 09:44, 25 April 2021 (UTC)

bit of OR here, so no place for it in the article, but in 2010 I had the task of migrating a substantial library from a storagetek silo (mixture of 9840 & 9940 if you're interested) to a new quantum library with LTO-6 or LTO-7, I forget... because the storagetek was quite an attractive piece of hardware, it had been installed right in the centre of the room whose operations it supported. by the time it went EOL, this was a less popular idea, & so its replacement was to go (against my protests about limited access & the idea of keeping less important material externalised) in the secure data centre, well away from operations. the room was only accessible by a handful of us, & in any case ran a 15% oxygen fire-supressant system, halon having been outlawed. some time during the migration, & after I had handed it over to ops & stepped away, this data centre was tested for airtightness. the usual way had been to install a pump in the room & see if it maintained higher than atmospheric pressure, but on this occasion the company hired to do the test opted for a technique involving a fine orange powder. I'll cut out the details... I sent pics of the mess to quantum, & they- by return of email- wrote off the library, all the tapes, the drives & six months of work. I've run into similar situations at my current employer, where two spectra libraries found themselves in the middle of a building site because the management here thought that they weren't important enough to protect &/or move away from concrete/steel/plaster dust. some of the grey deposits we were wiping off the tapes was magnetic- definitely from steel-cutting. we lost some data, some drives, sometimes whole tapes. I pointed out a number of times that this was the company's *archive*, & that when such organisations are in talks about multi-million dollar content deals (I won't name names, but you've heard of these companies, for sure), the stuff in those cabinets IS the content. it doesn't exist anywhere else. even if you've poked it up into 'the cloud', that's just a bunch of servers & tape libraries somewhere else.

duncanrmi (talk) 17:15, 9 May 2023 (UTC)

Really interesting material by Stoatwblr and Duncanrmi and should be published someplace. BTW, I doubt if the tape head's coil gets damaged by any dust; more likely is the magnetic structure is eroded leading to changes in both reading (MR element) and writing (inductive element). There is also a transient problem where the dust separates the head from the tape resulting in a bad write in addition to whatever physical damage it might do. Tom94022 (talk)

labels

As far as I know, there is a standard for barcode labels designed for robotic tape systems, and adopted by different tape manufacturers. Even more, as well as I know, LTO and DLT tapes are close enough to the same size that the same robots can be used, so the same labels system. For convenience, labels can be put on in the factory. So, while the standard isn't part of LTO (or DLT) it is commonly used with them, and so is probably reasonable for this article. Gah4 (talk) 08:42, 31 December 2019 (UTC)

Two sources added as requested. Sadly, the original specs are not public, but they match the IBM source. --Zac67 (talk) 10:58, 31 December 2019 (UTC)

@Zac67: Thanks for the sourcing. Can you identify the "original" spec, particularly as to its source and content? I would be surprised if the LTO Consortium provided such a spec but it could be. In the absence of such a consortium spec the paragraph may need wordsmithing to make it clear that there has been standardization amongst some robotic tape system manufacturers to allow for interchange and not a universal label standard beyond size and cartridge type identification. 17:40, 31 December 2019 (UTC)

"standardization amongst some [...] manufacturers" is exactly what the LTO Consortium is. It's not ANSI, ECMA, nor ISO.

• Please don't quote me out of context, the [...] was "robotic tape system manufacturers." Such a standardization is not necessarily an LTO Consortium's standard. Tom94022 (talk) 00:13, 1 January 2020 (UTC)

I've provided sources covering two thirds of that consortium, so exactly what are you asking? I once had access to the LTO-2 specs and it matched the IBM label specs verbatim back then (or at least 99%). I don't have the specs myself and can't cite them, sorry. Since you're stating that the (label) standard isn't part of LTO, do you have access to a newer version spec? Then we'd need to adapt the wording indeed. --Zac67 (talk) 17:55, 31 December 2019 (UTC)

Again please don't quote me out of context - I never said "the (label) standard isn't part of LTO" - to paraphrase what I said, is that I would be surprised if the LTO standard for label went beyond size of the label and location and format of cartridge type identification.

Actually none of the controlling partners of the LTO Consortium manufacture tape media so citing IBM and Quantum's standards as robotic suppliers is not particularly relevant to what the LTO Consortium standards if any say about cartridge labels. References from Sony or Fujifilm would be more persuasive. My guess is the LTO Consortium media standards say little about what can be printed or written in the user space on the label but that is just my guess. Likewise you to are guessing based upon ancient history that the LTO Consortium's standard for labels now requires (or suggests) USS-39 etc. Apparently there is no reliable source for this paragraph as written. The most we can say is that some robotics manufacturers have standardized on ?...USS-39 ..." for the label. Tom94022 (talk) 00:13, 1 January 2020 (UTC)

Frankly, the media manufacturers defining specs for the robotics is an absurd idea (and OR, of course). The media manufacturers license the specs from the consortium and plow away – they don't define anything by themselves, at least not likely. However, since the specs aren't publicly available, any guess or memory is as good as the other. I've paraphrased the text to state that barcode 39 is "commonly used" as we can hopefully agree on. --Zac67 (talk) 00:58, 1 January 2020 (UTC)

I didn't say the media manufacturers define the specs, they build to the consortium defined specs. You might take a look at Fujifilm Barcode Labeling which indicates labels can be customized to the buyers requirements. It also notes that "Barcode labeling is a necessity in data storage environments where libraries are utilized" which suggests the a standard comes from the library suppliers and not the LTO Consortium. I've somewhat further modified the paragraph to make this clear. Tom94022 (talk) 01:36, 1 January 2020 (UTC)

Also note "LTO Ultrium labels are a custom product. ... The options available to you are endless." Tom94022 (talk) 01:45, 1 January 2020 (UTC)

Customization is limited to the range of the encoded text/numbers, placement of text, code, additional logos etc. I haven't seen an offer to use a different barcode which wouldn't make too much sense unless you build your own library. Of course, you can print those labels yourself just as well (which we do at work since prices at low volume are a ripoff). --Zac67 (talk) 12:41, 1 January 2020 (UTC)

The spec is unofficially limited to 8 characters using type 39 barcodes by convention - as per https://www.sanspot.com/lto-guide

For what it's worth: Barcodes only matter if you're using a library and as such, sticking to the library makers' spec is "a very good idea"

IBM's standardisation is at https://www.ibm.com/support/pages/node/651699

The javascript label sheet generator at https://tapelabel.de/ is useful for compliant generation of your own labels

Using this convention The last 2 digits are reserved for the tape type (L1-9 for LTO9, CU for cleaning tapes. LTO10 and up TBA, but I assume it'll be LA-LZ)

- most libraries will use this to NOT put incompatible tapes into drives when there are mixed drive types installed

The tape label field in the cartridge MAM allows for 39 characters and most libraries will let you use whatever format you wish, but a lot of external software (EG: Veritape) assumes 6+2 and will have a hard time if you use anything else (voice of experience here....)

ie: You CAN use other conventions, but sooner or later you'll end up wishing you hadn't (guess how I found this out?) when you hit a library or software which can't cope ("Just because you CAN doesn't mean you SHOULD")

It should also be noted that use of paper labels is strongly _NOT_ recommended as fibres may detach and contaminate the drive head (the issue is the adhesive, not the fibre) - this rules out all A4 "LTO" label sheets - discovery of paper fibres with adhesive attached in the tape path may invalidate your support contract

The only LTO stamped "printable" polyester sheets available are all in US Letter format and hard to obtain in A4 countries (most of the rest of the world) but at about $2 a sheet (30 labels) they're still a lot cheaper than buying custom labelled LTOs ($2-$6 extra per tape).

Notes: Until we moved to laser-printed polyester LTO labels I had pretty good success using 18mm laminated label printer output (Brother TZ tapes, other makers are available) despite the "17mm" requirement of the labelling detent

- however these don't work well in Quantum i-series libraries (ex ADIC) and may not work terribly well in newer Spectralogic/Tandberg-Overland libraries due to newer video scanners (replacing the laser barcode readers)

- these newer scanners have a smaller field of view and are setup to expect the text above the barcode when the tape is in the drive - ie: barcode on the "bottom half" of the cartridge.

- Most labelling machines put text below the barcode, not above. The fix is to affix the labels 'upside down' if you use labelling machine output - the barcode reader doesn't care about code "direction", merely that it can be seen.

Stoatwblr (talk) 00:00, 10 November 2020 (UTC)

compression

Many of us, and especially hardware people, tend to think of anything that can be one or zero, with any probability, as a bit, and so eight of them as a byte, and some larger number as a gigabyte. But in information theory it is not so simple. Counting bits depends on the probabilities, and so something that can be either 0 or 1, might count as less than one bit. Data compression is related to information theory, and so this changes the way bits and bytes are counted. Personally, I would rather they count physical bits, not information theory bits, but that would be WP:OR, or maybe just WP:NPOV. In either case, this article has to follow the way LTO defines it. Gah4 (talk) 22:52, 1 January 2020 (UTC)

Compression isn't really about a number of bits or bytes but rather about the data entropy, or the 'true amount of information' – the data's amount of unpredictability. That said, we need to make clear what the physical capacites are, that the nominal compression ratio changes with generations, and what compressed capacity actually means. Right now, that already comes across pretty well imho, but improving it without too much technobabble probably won't hurt. --Zac67 (talk) 23:08, 1 January 2020 (UTC)

I agree that compression in tape storage is reasonably well treated in this article and elsewhere. Of course improvement is always encouraged. Tom94022 (talk) 23:35, 1 January 2020 (UTC)

Yes, I was partly mentioning it based on an edit summary. But also, I have always wondered about it. Some years ago, I remember using a Unix dump command that had to be told how big a tape was, would write an appropriate amount, and then ask for the next reel (or cartridge). If you can't reliably determine the tape size, then compression doesn't help. In any case, the article can't ignore compression because LTO doesn't ignore it. Gah4 (talk) 00:46, 2 January 2020 (UTC)

The problem you're mentioning is a software issue, when the dump utility isn't able to sense the EOT and runs into an error. It is not caused by the underlying technology, only the inability to use it. --Zac67 (talk) 08:44, 2 January 2020 (UTC)

I believe it is some hardware and some software. Some tape systems don't provide the ability to sense EOT and recover after a change of tape. The fix was to give tapes a fixed size and let the software write that much, avoiding EOT. The way it is supposed to work on 9 track reel tapes, is that there is an EOT marker which signals the drive, but the current block is still written. Some cartridge tapes don't have that ability. I usually do Unix-like dumps with tar, and I am not sure what it does at EOT. Gah4 (talk) 13:30, 2 January 2020 (UTC)

Our Real World compression on LTOs is more like 1.1:1 to 1.2:1 on most binary data (if that). The kinds of claimed compression cited are only applicable to low-entropy stuff like textfiles or text-based origins and claiming 3:1 is "well past the limits of credulity" under normal operating conditions

Regarding capacity, compression and tape size: LTO tapes have a preformatted servo track ex-factory. It's critical for serpentine tracking but also gives exact positioning information. The drive always knows where it is and whilst the unix dump code mentioned was spectacularly brainless (I'm still using it on VMS, these aren't DLTs or DATs or other "blank" media. They tell the server not only when EOT is reached but there's also a signal given 100-300MB before EOT as advance warning. (whether the software takes any notice is another matter. Most tar implementations do) Stoatwblr (talk) 00:16, 10 November 2020 (UTC)

A Commons file used on this page or its Wikidata item has been nominated for speedy deletion

The following Wikimedia Commons file used on this page or its Wikidata item has been nominated for speedy deletion:

• LTO-5 Ultrium Data Cartridge.png

You can see the reason for deletion at the file description page linked above. —Community Tech bot (talk) 16:22, 19 February 2020 (UTC)

Reference 95

"In 2019 about 80 percent of business (then modern) had data stored on tape."

Looks like the claim on the reference site is unsourced. And the claim doesn't sound right. Should it be removed? C5H10O5 (talk) 10:51, 8 July 2021 (UTC)

C5H10O5, there are only 95 refs at this time. Can you clarify by author or title which ref ref we're talking about here? ~Kvng (talk) 13:54, 11 July 2021 (UTC)

Kvng, it's currently the last source (95th) – https://www.nakivo.com/blog/debunking-tape-backup-myths-in-2019-overview/

C5H10O5, why doesn't the claim sound right? All large businesses still use tape and the claim is sourced. I have just modified the wording so it's closer to what the source says. --Zac67 (talk) 14:26, 11 July 2021 (UTC)

I modified the ref to use the cite web template and we can see the claim is sourced. The claim doesn't sound true to me either, particularly since it is not limited in any way- all businesses, world wide? I doubt it! Maybe all large international companies? But I don't currently have a better source so it should stand until we have a better RS. Tom94022 (talk) 06:41, 12 July 2021 (UTC)

Here is another source with a similar unqualified usage of 90%. Maybe the article can say a large percentage of businesses still use tape and give these two citations. But I still think the percentages are too high. Tom94022 (talk) 06:47, 12 July 2021 (UTC)

Notice that the claim is that tape is used (in some capacity) in 80-90% of businesses (of some class). Without the parenthetical information, this gives the impression that almost everyone is using tape for almost all their backup which is what a tape backup vendor such as Nakivo (the source of the information) would like you to believe. That's probably not what is actually happening. Tom94022's new source gives a couple less slippery numbers. Specifically, "The typical organization stored 21 percent of its backup data on tape." And, "67 percent of companies that use tape use it mostly for archiving." ~Kvng (talk) 14:06, 15 July 2021 (UTC)

diagram of track layout

can anyone provide a quick-&-dirty picture of the track layout vs the serpentine path of a single track, to illustrate how this enormous amount of data is written to tape in a timely fashion without the use of rotating heads? how has this evolved with better materials? how is retro-compatibility ensured & what behoves the manufacturers to ensure backwards-compatibility rather than making everyone do a migration when they upgrade (say) from LTO-6 to LTO-7?

duncanrmi (talk) 17:04, 9 May 2023 (UTC)