Hva er fordelen ved å bruke Tar-filformatet i dag?

Tar arkiveringsformatet er, i beregningsår, et veritabelt Metuselah, men det er fortsatt i stor grad i bruk i dag. Hva gjør tjæreformatet så nyttig lenge etter oppstarten?

Dagens Spørsmål & Svar-sesjon kommer til oss med høflighet av SuperUser-en underavdeling av Stack Exchange, en fellesskapsdrevet gruppering av Q & A-nettsteder.

Spørsmålet

SuperUser leser MarcusJ er nysgjerrig på tjæreformatet og hvorfor bruker vi det fortsatt etter alle disse årene:

Jeg vet at tjære ble laget for tape arkiver tilbake på dagen, men i dag har vi arkivfilformater som både aggregatfiler og utfører komprimering i samme logiske filformat.

spørsmål:

Er det en ytelsesstraff under aggregering / kompresjon / dekompresjonstrinn for bruk av tjære innkapslet i gzip eller bzip2, sammenlignet med å bruke et filformat som gjør aggregering og komprimering i samme datastruktur? Anta at kjøretiden til kompressoren som sammenlignes er identisk (for eksempel gzip og deflate er like).

Er det funksjoner i tarfilformatet som andre filformater, for eksempel .7z og .zip, ikke har?

Siden tjære er et gammelt filformat og nyere filformater eksisterer i dag, hvorfor er tjære (enten innkapslet i gzip, bzip2 eller til og med den nye xz) som fortsatt er så mye brukt i dag på GNU / Linux, Android, BSD og andre slike UNIX operativsystemer, for filoverføringer, programkilde og binære nedlastinger, og noen ganger til og med som et pakkehåndteringsformat?

Det er et helt fornuftig spørsmål; så mye har endret seg i databehandlingsverdenen de siste tretti årene, men vi bruker fortsatt tarformatet. Hva er historien?

Svaret

SuperUser bidragsyter Allquixotic gir litt innsikt i tjæreformatets levetid og funksjonalitet:

Del 1: Ytelse

Her er en sammenligning av to separate arbeidsflyter og hva de gjør.

Du har en fil på disken blah.tar.gz som er 1 GB gzip-komprimerte data som, når de er ukomprimert, opptar 2 GB (slik at et komprimeringsforhold på 50%).

Måten du ville opprette dette på, hvis du skulle arkivere og komprimere separat, ville være:
tar cf blah.tar filer ... 
Dette ville resultere i blah.tar som bare er aggregering av filer ... i ukomprimert form.

Da ville du gjøre det
gzip blah.tar 
Dette ville lese innholdet av blah.tar fra disk, komprimere dem gjennom gzip-komprimeringsalgoritmen, skriv innholdet til blah.tar.gz, Deretter fjerner du (slett) filen blah.tar.

La oss dekomprimere nå!

Vei 1

Du har blah.tar.gz, på en eller annen måte.

Du bestemmer deg for å kjøre:
gunzip blah.tar.gz 
Dette vil

LES 1GB komprimert data innhold av blah.tar.gz.

PROSESS de komprimerte dataene gjennom gzip dekompressor i minnet.

Siden minnesbufferen fyller opp med en "blokk" som er verdt data, SKRIV de ukomprimerte dataene inn i filenblah.tar på disk og gjenta til alle komprimerte data er lest.

Fjern koblingen (slett) filen blah.tar.gz.

Nå har du blah.tar på disk, som er ukomprimert, men inneholder en eller flere filer i den, med svært lav datastruktur overhead. Filstørrelsen er sannsynligvis et par byte større enn summen av alle fildataene ville være.

Du løper:
tar xvf blah.tar 
Dette vil

LES 2GB ukomprimert datainnhold av blah.tar og tjære filformatets datastrukturer, inkludert informasjon om filtillatelser, filnavn, kataloger, etc..

SKRIV til å diskere 2 GB data og metadataene. Dette innebærer: å oversette data struktur / metadata informasjon til å lage nye filer og kataloger på disk etter behov, eller omskrive eksisterende filer og kataloger med nytt datainnhold.

Den totale data vi LESE fra disk i denne prosessen var 1GB (for gunzip) + 2GB (for tjære) = 3GB.

Den totale data vi SKREV til disk i denne prosessen var 2 GB (for gunzip) + 2 GB (for tjære) + noen byte for metadata = ca 4 GB.

Vei 2

Du har blah.tar.gz, på en eller annen måte.

Du bestemmer deg for å kjøre:
tar xvzf blah.tar.gz 
Dette vil

LES 1GB komprimert data innhold av blah.tar.gz, en blokk om gangen, til minne.

PROSESS de komprimerte dataene gjennom gzip dekompressor i minnet.

Når minnebufferen fylles opp, vil det rør disse dataene, i minnet, gjennom til tjære filformat parser, som vil lese informasjon om metadata etc. og de ukomprimerte fildataene.

Som minnebufferen fylles opp i tjære fil parser, vil den SKRIVE de ukomprimerte dataene til disk, ved å lage filer og kataloger og fylle dem opp med ukomprimert innhold.

Den totale data vi LESE fra disk i denne prosessen var 1 GB komprimert data, periode.

Den totale data vi SKREV til disk i denne prosessen var 2 GB ukomprimert data + noen byte for metadata = ca 2 GB.

Hvis du merker, mengden av disk I / O i Vei 2 er identisk til disken I / O utført av, si Glidelås eller7-Zip programmer, justering for eventuelle forskjeller i kompresjonsforhold.

Og hvis kompresjonsforholdet er din bekymring, bruk xz kompressor til innkapsling tjære, og du har LZMA2'ed TAR-arkiv, som er like effektiv som den mest avanserte algoritmen tilgjengelig for 7-Zip :-)

Del 2: Funksjoner

tjære lagrer UNIX-tillatelser i filmetadataene sine, og er meget kjent og testet for å kunne pakke opp en katalog med alle slags forskjellige tillatelser, symbolske lenker, osv. Det er flere enn noen få tilfeller der man kanskje trenger å spole en masse filer inn i en enkelt fil eller stream, men ikke nødvendigvis komprimere den (selv om komprimering er nyttig og ofte brukt).

Del 3: Kompatibilitet

Mange verktøy distribueres i kilde eller binær form som .tar.gz eller .tar.bz2 fordi det er et "laveste fellesnævner" filformat: I likhet med de fleste Windows-brukere har tilgang til .zip eller .rar dekompressorer, de fleste Linux-installasjoner, selv de mest grunnleggende, vil ha tilgang til minst tjære og gunzip, uansett hvor gammel eller paret. Selv Android-firmware har tilgang til disse verktøyene.

Nye prosjekter som målretter publikum som kjører moderne distribusjoner, kan meget godt distribueres i et mer moderne format, for eksempel .tar.xz (ved hjelp av komprimeringsformatet Xz (LZMA), som komprimerer bedre enn gzip eller bzip2) eller .7z, noe som ligner på Zip- eller Rar-filformatene ved at det både komprimerer og spesifiserer en oppsett for innkapsling av flere filer til en enkelt fil.

Du ser ikke .7z brukt oftere av samme grunn at musikk ikke selges fra nettbutikkbutikker i helt nye formater som Opus, eller video i WebM. Kompatibilitet med folk som kjører gamle eller svært grunnleggende systemer.

Har du noe å legge til forklaringen? Lyde av i kommentarene. Vil du lese flere svar fra andre tech-savvy Stack Exchange-brukere? Sjekk ut hele diskusjonstråden her.