Four decades of magnetic tapes How have they

  • Slides: 29
Download presentation
Four decades of magnetic tapes: (How) (have) they managed to survive(? ) • Why

Four decades of magnetic tapes: (How) (have) they managed to survive(? ) • Why has tape survived at all? • At CERN in 1972 (as a visitor ) I used a FORTRAN analysis program • The program was on two trays of punched cards • Data was then stored in a really modern manner, on 7 -track tapes!

Tape has survived, but by a slim margin 70 60 50 40 LTO 30

Tape has survived, but by a slim margin 70 60 50 40 LTO 30 NAND HDD 20 10 0 2008 2009 2010 2011 Revenues, $Bn 2012

A 1972 tape (and user? ) problem • A user of that era ,

A 1972 tape (and user? ) problem • A user of that era , optimistically clutching his card deck, is discussing directly his problem with the IBM operator. • Problems and users are closely correlated….

Disk (far) cheaper than tape • Disk storage existed then, but was extremely expensive.

Disk (far) cheaper than tape • Disk storage existed then, but was extremely expensive. Heads, motor, power, plugs, host • Users had to keep data on tape, of questionable reliability…. . But no motors, power, …. • At about this time the main CERN computer centre moved to 513, and the tape reels moved to the basement. • An unfortunate compromise made this rather inconvenient for the next thirty years: every tape requested had to be carried up a spiral staircase to the drives.

IBM 350 RAMAC PDP DECtape 1956, 5 Mch, 8 Kch/s IO 1970, 144 K

IBM 350 RAMAC PDP DECtape 1956, 5 Mch, 8 Kch/s IO 1970, 144 K 18_ bit words

CDC 7600 • Here is CDC’s 7600, the principal resident of the new centre,

CDC 7600 • Here is CDC’s 7600, the principal resident of the new centre, an extremely advanced machine, which read tapes rather indirectly via a smaller CDC 6400 or 6500 as a ‘front-end’. • It was easy to crash this machine by reading an unusual tape via CDC Scope 2. 1 and 6/7 RM

CDC engineer and 64 K • Not much at all was reliable in 1974:

CDC engineer and 64 K • Not much at all was reliable in 1974: here is a 64 kilobit stack from the CDC 6600 in ‘maintenance’ • No chance whatsoever of 5 or 6 sigma reliability: just 1 was surprising.

 • In 1974 I joined ‘DD’, and one of the main problems (apart

• In 1974 I joined ‘DD’, and one of the main problems (apart from questions about PATCHY) was the unreliability of the tape subsystem • This was compounded by the users themselves, who regularly didn’t know what was on their tapes or how to read them • Disk still being surprisingly expensive, tape numbers ballooned until we were ‘archiving’ more than half of them. It would probably be then that Sverre and the other curious folk known as ‘system programmers’ were trying to do the tricky task of adding reliability to the tape systems, where all the data still lurked

 • Note the presence of no fewer than 4 staff (one is a

• Note the presence of no fewer than 4 staff (one is a senior CDC manager) apparently needed to operate 3 tape drives!

Better drives help • The self-threading tape reel had now arrived, as well as

Better drives help • The self-threading tape reel had now arrived, as well as 9 tracks, removing the need to remove the tape case (and put it back), reducing work • Still, no user data resided permanently on disk. • The CDC Scope 2. 1 operating system was able to stay alive sometimes for a day or more…….

How to gain reliability and handle more data? • A Boeing engineer’s famous reply

How to gain reliability and handle more data? • A Boeing engineer’s famous reply when asked what he did was that his job was • ‘To simplificate and add lightness’ • For tape handling it’s the same, really: – Fewer errors = better drives and media – Less work = Fewer bits of media per GB – Even less work = automation

IBM’s 3850 MSS: a working system! (despite being tape, really)

IBM’s 3850 MSS: a working system! (despite being tape, really)

New IBM drives and media The last 200 MB tape • Tape reliability took

New IBM drives and media The last 200 MB tape • Tape reliability took a big jump forward with the self-enclosed and lightweight IBM 3480 type of cartridge. There were still many drive builders and media suppliers…. .

Drives go below • Growing tape demands led to a need for far more

Drives go below • Growing tape demands led to a need for far more space and many more drives. Eventually most moved to the basement. Here the old IBM and CDC cabling to drives is being removed from the false floor….

IBM-Haushahn automation prototype 3480 and TA 90: no photo! Considered were; and Comparex Proved

IBM-Haushahn automation prototype 3480 and TA 90: no photo! Considered were; and Comparex Proved hard to maintain, and was replaced by IBM 3495

The IBM 3495 (and 3494) We have a problem! Connected by IBM channel, only

The IBM 3495 (and 3494) We have a problem! Connected by IBM channel, only 3480 and 3490 drives and media

IBM 3494 • The 3590 Magstar, 10 GB now (but not SCSI)

IBM 3494 • The 3590 Magstar, 10 GB now (but not SCSI)

STK, Redwood, Powderhorns • Things are a little calmer… • SCSI connect, 10/25/50 GB

STK, Redwood, Powderhorns • Things are a little calmer… • SCSI connect, 10/25/50 GB • Potential capacity to automate everything

The STK Redwood: 10/25/50 GB • 50 Kg, helical, lots of parts, tricky to

The STK Redwood: 10/25/50 GB • 50 Kg, helical, lots of parts, tricky to keep running

Others, such as DEC DLT robot TL 820 Popular and low cost drive, but

Others, such as DEC DLT robot TL 820 Popular and low cost drive, but robotics small, tricky….

So, de we automate everything now? • Manual 3480 and 3490 to Redwood •

So, de we automate everything now? • Manual 3480 and 3490 to Redwood • What about the rest (DLTs, Exabytes, …)?

Mass copy to high density done • • STK 9840 and 9940 now replace

Mass copy to high density done • • STK 9840 and 9940 now replace Redwood Drives and media are now reliable Down to a tiny operational staff Now, can we get rid of the users? Or ignore them, in a sense? – Disk still too expensive for everything, tape persists – Needs software to hide the tape layer – HPSS, Lachmann Legent, ADSM, Eurostore, …. • CASTOR does this job ( but needs repack…. )

CASTOR tape pool….

CASTOR tape pool….

Not ALL problems have gone!

Not ALL problems have gone!

Dual supplier era, STK and IBM • STK/Sun/Oracle , T 10000 and successors •

Dual supplier era, STK and IBM • STK/Sun/Oracle , T 10000 and successors • SL 8500 library replaces Powderhorn • Tape faster than disk! (still cheaper too)

Dual supplier era, STK and IBM • IBM TS 3500 Library • 3590 successors:

Dual supplier era, STK and IBM • IBM TS 3500 Library • 3590 successors: – TS 1130, TS 1140

Nearly there now, after 40 years • • No operators High capacity, fast drives

Nearly there now, after 40 years • • No operators High capacity, fast drives High capacity, quite fast libraries No need for users (to know about tape) Media needs no power, has a long(ish) life Better data security possible if desired Can the CERN software disappear too? Disk is a cheap throwaway commodity now!

People were needed, though, to do this (even if they didn’t know they were

People were needed, though, to do this (even if they didn’t know they were helping) Antonio Maver, Hugo Caçote, Jean-Phillipe Baud, Jean-Damien Durand, Fabien Collin, Ingo Augustin, David Asbury, Eric Mc. Intosh, Jean-Claude Juvet, Ans Oude-Moleman, Ian Mc. Laren, Les Robertson, Tony Cass, Jamie Shiers, Harry Renshall, Tim Bell, Dietrich Wiegandt, Ben Segal, Christian Letertre, Ben Segal, Tony Osborne, Gordon Lee, Linda Whitley, Judith Richards, Jean-Claude Brahier, Bertrand Oppliger, Johannes Gerber, Marcel Würtrich, Jacques Rault, Pasquale Di Cesare, Jean-Michel Thiboud, Alain Bruni, Ed Aden, Hal Mc. Ilroy, Dick Replogle, Bob. Wilson, Pete Colton, Vittorio Frigo, Silvano De Gennaro, Jacqueline Gudet, Gildas Auffret, Jean. Claude Bourigault, Klaus Pluntke, Dick Minchin, Lenny Hoejenbos, Vlado Bahyl, Jean-Francois Lachavanne (in no particular order, and others, whom I may have missed)