[LTO tape]Hoeveel past er effectief op een Gen1 tape?

[JumpStart]

De makkelijke instapper op deze vraag is natuurlijk de antieke valkuil van omrekenen. Vermenigvuldig/deel je met/door 1000 of met/door 1024?

In tegenstelling tot de harde schijf industrie, waar je het nog wel eens in kleine lettertjes "1 MB equals 1.000.000 bytes" terug kan vinden, staat de juiste conversiefactor bij tape capaciteit niet vermeld. Bij gebrek aan zekerheid zet ik mijn geld dus maar in op het worst case scenario, rekenen in eenheden van 1000, dus 1 Kb is 1000 byte. 1 MB is 1000 kb, enzovoorts.

Op een generatie 1 LTO tape, met een opgegeven capaciteit van 100/200 GB (waarbij andere kleine lettertjes bij "200 GB" al aangeven dat men hier de gebruikelijke 2:1 compressie factor veronderstelt) kan dus 100.000.000.000 bytes. Wat neerkomt op 93,13 gigabytes, rekenend met de juiste 1024 factor. Scheelt nogal, zeker als je per tape archiveert, en je dus spanning niet wil hebben. Afvullen op 93 of 100 GB maakt dan nog aanzienlijk verschil.

Wat er verder ook nog bij komt kijken is eventuele benutting van overcapaciteit. Een beetje wat overburnen van CD-R is. Zoveel ervaring heb ik niet met tapes, ik zou niet weten of zoiets kan. Bestaat zoiets? Kan een LTO tapestreamer er nog een procentje bijpakken of houdt het na 100.000.000.000 bytes op?

Google helpt me niet veel verder dan vertellen dat er op een LTO tape van de eerste generatie effectief 100 GB past. Hier dus géén kleine lettertjes met de juiste conversiefactor, ook niet DLT of DDS. Over het benutten van eventuele overcapaciteit heb ik ook niets gevonden.

Nou ben ik momenteel het nodige aan ghost images en rar archieven op een LTO 100/200 tape aan het wegzetten. Meer archiveren dan backuppen in feite. Dit gaat met behulp van een HP Ultrium LTO generation 1 tapestreamer, Maxwell LTO 100/200 GB tapes en Tapeware versie 7.00.

Wat ik dus probeer uit te vinden is hoeveel ik nu, uitgaande van 1:1 opslag zonder hardware- of softwarematige compressie, op 1 tape kwijt kan. Iemand?

[ Voor 2% gewijzigd door JumpStart op 24-03-2005 23:38 . Reden: minor typo ]

[DeBolle]

De precieze hoeveelheid is inderdaad niet exact op de byte af te benoemen. Het Ultrium format biedt fysiek ruimte aan een (bijna belachelijke) hoeveelheid parameters die allen weer afhankelijk zijn van de manier waarop de data wordt aangeleverd. Gebruikt de backupmethode bijvoorbeeld Fast Search Marks, EOF of Check Marks tussen de bestanden? Zo ja, wordt daarbij padding toegepast (afronding op hele blokken van bijv. 64KB) en is de blocksize dan variabel of vast? Als de standaard blocksize van 256KB wordt gebruikt, kan de backupmethode ook gedeelten van blocks gebruiken of wordt elk block aangevuld tot 256KB?
De datacompressie en de variabele snelheid gooien ook roet in het eten voor een exacte berekening - er zijn behoorlijke verschillen tussen de drie fabrikanten (HP, IBM en Certance/Seagate) bij de gebruikte compressie. Hierbij kan het voorkomen dat bij al gecomprimeerde data er juist expansie plaatsvindt.
Het fysieke format biedt ruimte aan 384 tracks van elk 4880 bits per mm tape. Als de exacte gebruikte lengte bekend is kan het aantal bits worden berekend wat fysiek op een tape past - dat is eigenlijk alles wat we kunnen bepalen.
Voor een redelijk in-depth white paper over de capaciteit van een Ultrium kun je http://www.exabyte.com/su...pers/ibmlto-2overview.pdf eens doorbladeren.
In de praktijk heb ik overigens gezien dat op een Ultrium 1 tape gemiddeld 207GB aan data past, waarbij de data een mengeling is van programmatuur, OS en gebruikersdata en totaal ongeveer 800GB diskruimte inneemt. Voor alle duidelijkheid, hierbij reken ik gewoon met de standaard 1024 bytes per KB en 1024 KB in een GB
Voor wat betreft de door jou gebruikte configuratie zul je verschil moeten maken tussen de 215 en de 230 van HP, de eerste heeft vooral een langzamere interface waardoor de eventuele compressie niet altijd voldoende data op tijd binnen heeft om de tape draaiende te houden, waardoor er effectief minder op een tape zou passen. De 230 is meetbaar en merkbaar sneller maar een directe vergelijking van de exacte hoeveelheid data heb ik nog nooit gedaan omdat ik geen 215 tot mijn beschikking meer heb.
Ik heb wel verschil kunnen meten tussen HP en IBM drives, waarbij in de door mij gebruikte configuraties de IBM drives in het voordeel waren. Deze waren sneller tijdens restores en er paste een paar GB meer op - laten we dat op ongeveer 4% houden.
Bij HP blijkt het in de praktijk erg afhankelijk van de gebruikte firmware, als je de LT&T tool gebruikt zul je zelf ook merken dat er erg veel verschillende versies firmware zijn voor dezelfde hardware. Ik heb tapes in handen gehad die alleen nog te lezen waren in drives met exact dezelfde firmware, terwijl niet duidelijk was wat de verschillen tussen de firmwares zijn.
Voor een exacte meting ben je uiteindelijk aangewezen op het vullen van een tape van begin tot eind met een filler tooltje (dd vanuit /dev/null ligt voor de hand) waarbij je datacompressie uitgeschakeld hebt. Dat het per tape kan verschillen zal je nu duidelijk zijn

[JumpStart]

Hmmm ...

In ieder geval bedankt voor de uitleg.

Als het dus tapedrive, tape, firmware en compressie methode afhankelijk is dan is een simpel antwoord niet eens mogelijk. Het wordt dan dus trial-and-error uitproberen, of ik moet op gewoon maar op safe spelen en onder de 100.000.000.000 bytes blijven. Gezien de aard van de data (simulatie resultaten met een comprimeerbaarheid van bijna nul) heeft het weinig zin om daarop in te zetten en gokken op een paar procent ruimtewinst.