[Løst] Problemer med "full" 3592E05 tape

[quarkey]

Hei folkens!

 

Jeg er litt usikker på hvor denne tråden passer inn, men siden det har med lagring å gjøre så regner jeg med at det passer inn her. Uansett…

 

… Jeg har en IBM 3592E05 som jeg skal skrive ut en del data til. Denne tapen rommer 500GB uten komprimering.

 

Jeg har totalt ca 367GB (totalt antall filer: 2202) med data som skal skrives til tapen, men får feilmeldinger etter ca 300GB, og systemet spytter ut melding om at tapen er full.

 

Displayet på 3592 Dual Jaguar driven viser også at media er fullt !

 

Dette virker jo litt rart. Skal jo i teorien ha ca 130GB igjen på tapen etter at dataene er blitt skrevet…

 

Jeg mistenker at tapen blir full av EOF marks som ikke regnes med i størrelsen av dataen på disk, da EOF etter fil/records fungerer kun på tape.

 

Dataene MÅ skrives med 37 434 EOFs for at datasettet skal følge SEGD 8015 rev 2 standarden.

 

Så da er spørsmålene mine:

 

1) Fylles tapen opp med så mange EOFs at selve båndet blir brukt opp, slik at systemet rapporterer at media er fullt?

2) Hvor mye fysisk båndplass tar en EOF?

3) Hvor mye plass i kb eller mb tar en EOF?

 

PS! For de som lurer på hvilken standard dette er, så er opptak av seismiske målinger i enten jordskjelv eller seismiske målinger av havbunnen.

 

På forhånd takk!

Endret 1. november 2010 av quarkey

[quarkey]

Kan også nevne at dataene blir skrevet ut fra unix solaris 10, men med ukjent i/o bibliotek. Det kan tenkes at det bruker samme funksjoner som “dd”.

[Varj]

kan neppe hjelpe deg i særlig grad med ditt svært spesifikke problem knyttet opp mot en spesifikk propertiær løsning, men det er jo en grunn til at "tar" ble laget for å skrive mange filer til tape som en stor fil.

så det virker rimelig å anta at det er svært ugunstig med en haug EOF, både ytelsesmessig og plassmessig.

 

kan dog umulig tenke meg at selve entry'en tar særlig med plass, men den må nok aligne mot nærmeste blokk, så da må man vite blokkstørrelsen du bruker.

 

standard i windows er gjerne 64kB, men i Solaris er det vanlig med både 128kB og 256kb (og kan skrus helt opp til 8MB).

[Varj]

siden du nevner "dd", så settes her block size med bryteren "bs=X", men da du nevner at den faktiske løsningen er ukjent, så må du nesten grave litt.

[quarkey]

TAR er dessverre uaktuelt i denne sammenheng, da det må være EOF mellom records. Og det er litt vanskelig å få til hvis ikke man har en form for enkapsulering som deler filene på rett plass. (ikke minst finner frem igjen).

 

Kan vise deg et lite utdrag av datastrukturen. Blocksize er litt annerledes på seismikk data enn vanlige filer. Fungerer veldig dårlig med å overkjøre med bs=xxx i DD

 

Seismikk data:

file 1: record 1: size 128
file 1: eof after 1 records: 128 bytes
file 2: record 1: size 16128
file 2: records 2 to 1489: size 7060
file 2: eof after 1489 records: 10521408 bytes
file 3: record 1: size 16128
file 3: records 2 to 1489: size 7060
file 3: eof after 1489 records: 10521408 bytes
file 4: record 1: size 16128
file 4: records 2 to 1489: size 7060
file 4: eof after 1489 records: 10521408 bytes
file 5: record 1: size 16128
file 5: records 2 to 1489: size 7060
file 5: eof after 1489 records: 10521408 bytes
file 6: record 1: size 16128
file 6: records 2 to 1489: size 7060
file 6: eof after 1489 records: 10521408 bytes
file 7: record 1: size 16128
file 7: records 2 to 1489: size 7060
file 7: eof after 1489 records: 10521408 bytes
… osv opp til 35 000 ca

 

Seismikk data som kopiert til tape med TAR:

file 1: records 1 to 66859: size 10240
file 1: eof after 66859 records: 684636160 bytes eot
total length: 684636160 bytes

Dataene ser sånn ut enten om det er 1000 filer eller 10 filer.

 

Når det gjelder ytelsesmessig så har EOF ingen betydning for oss på verken hastigheter til 3592 drive eller kopiering til disk. Skriver data med 70-100MB/s. Men dette er jo helt klart et problem for folk som faktisk trenger heftig drive / disk hastigheter.

 

 

Men her sporer vi litt av på dataen. Spørsmålet i bunn og grunn er hvor mye plass på båndet tar en EOF? Hehe

Endret 1. november 2010 av quarkey

[Varj]

vil som sagt tippe at EOF tar 1x blokkstørrelse, det gir ihvertfall mening i mitt hode

[quarkey]

Har kommet frem til problemet, EOF tar ca hele 66Gb på tapen, og ca 60-70Gb waste i å fullføre blokkene.

 

Ikke akkurat noe effektiv bruk av størrelsen på tape… Men det skal også nevnes at data ble laget på tidlig 80-tallet, og har ikke blitt videre prosessert!