Quali sono le differenze tra bsdtar e GNU tar?

Ho sempre usato GNU tar. Tuttavia, tutte le distribuzioni GNU / Linux che ho visto vengono spedite bsdtarnei loro repository. L'ho anche visto installato di default in alcuni, IIRC. So per certo che Arch GNU / Linux lo richiede come parte di basedevel(forse base, ma non ne sono sicuro), come l'ho visto in PKGBUILD.

Perché dovresti usare al bsdtarposto di GNU tar? Quali sono i vantaggi?

Si noti che sono la persona che ha chiesto Quali sono le principali differenze tra BSD e GNU / Linux userland? .

Ubuntu bsdtarè in realtà l'implementazione tar inclusa libarchive; e questo dovrebbe essere differenziato dal classico bsdtar. Alcune varianti di BSD usano libarchiveper la loro implementazione tar, ad esempio FreeBSD.

GNUtarsupporta le altre varianti di tar e il rilevamento automatico della compressione.

Mentre la visualizzazione ha incollato il turbinio di Ubuntu, ci sono alcune cose specifiche per libarchive:

1. libarchiveè per definizione una biblioteca, diversa da quella classica bsdtare GNUtarin quel modo.
2. libarchive non è in grado di leggere alcune vecchie varianti oscure di tar GNU, in particolare la codifica di alcune intestazioni in base64, quindi il file tar sarebbe ASCII pulito a 7 bit (questo era il caso per 1.13.6-1.13.11 e cambiato in 1.13.12 , quel codice è stato ufficialmente in tar solo per 2 settimane)
3. libarchive's bsdtarleggerà i file non-tar (quale ZIP, ISO9660, cpio), ma bsdtar classica non lo faranno.

Ora che ci siamo libarchiveallontanati, si tratta principalmente di ciò che è supportato nella musica classica bsdtar.

Puoi vedere tu stesso le pagine man:

• GNU tar (1)
• Tar FreeBSD (1) - basato su libarchive
• Tar NetBSD (1)
• OpenBSD tar (1)
• Standard / Schily tar (1) - la più antica implementazione gratuita di tar, nessuna eredità rispetto a nessun altro
• busybox (1) - Implementazione mini tar per BusyBox, comune nei sistemi embedded

Nella tua domanda originale, hai chiesto quali sono i vantaggi del classico bsdtare non sono sicuro che ce ne siano davvero. L'unica volta che conta davvero è se stai cercando di scrivere script di shell che devono funzionare su tutti i sistemi; devi assicurarti che ciò a cui passi tarsia effettivamente valido in tutte le varianti.

GNUtar, libarchive's bsdtar, classic bsdtar, stare BusyBox' s tarsono certamente le implementazioni tar che ti imbatterai nella maggior parte delle volte, ma sono certo che ce ne sono altre là fuori (ad esempio QNX iniziale). libarchive/ GNUtar/ starsono i più ricchi di funzionalità, ma per molti versi si sono discostati da molto dagli standard originali (forse per il meglio).

BSDTAR vs TAR e molto altro ancora

Ecco un vantaggio !!

Ho intenzione di entrare in 5 argomenti qui (e andare fuori tema, ma coprirà anche quello che vuoi):

1. bsdtar vs tar
2. file sparsi vs no
3. lime / luns spessi e sottili con btrfs
4. lime / luns spessi e sottili senza btrfs
5. diff tra spessore e spessore e come non si applica solo alle suole

bsdtar gestisce i file sparsi meglio del normale tar

• bsdtar prenderà tutti gli zeri e li metaderà appena
• tar processerà effettivamente ogni zero

* esempio: immagina un file sparso da 20 TB (chiamato biglun) con 10 mega di dati in tutto lo sparsefile da 20 TB (biglun) ... ora dato che si tratta di un file sparso, ci vorranno solo 10 mega sull'unità.

Come creare un file sparse:

File Sparse - come crearlo - rilevarlo - tutto i file Sparse sono come dei "sottili" luns (se dovessi usarlo per un lun). le suole "spesse" sarebbero una storia diversa.

* torna all'argomento:

• tarare il biglun farà passare il tar attraverso tutti i 10 mega insieme a tutti i ~ 20tb peggio degli zero sparsi in tutto il lun ... presumo ci vorrà del tempo, e il file tar sarà abbastanza grande. Inoltre - estraendolo - non ho mai fatto un estratto di un file tar di un file sparse, ma potrebbe non essere carino; Potrei sbagliarmi qui.

• bsdtarring il biglun elaborerà solo i 10 mega di dati e creerà piccoli metadati per ~ 20 tb di zeri.

Beneficiare? Bene molti di loro; Ho appena scritto alcuni sopra.

È simile a rsync vs cp

• Inoltre, se si sincronizza un file sparso gigante, si comporterà come tar
• Se si cp un file gigante, si comporterà automaticamente come bsdtar (è possibile modificare il comportamento di cp per superare gli zero o non superare gli zero)

Personalmente, mi piace immaginare file sparsi come luns sottili e file regolari come luns spessi ...

L'argomento successivo è BTRFS thin vs thick luns:

• Con filesystem come BTRFS , i thin lun sono file sparsi (rendili troncati, come nel documento wiki).

   truncate -s <size in kilobytes> filename
  

  suggerimento: backup con bsdtar , copia con cp

• i lun di spessore sono file regolari con l'attributo + C (+ C in modo che non renda COW, copia su scrittura, in modo che tutte le scritture rimangano sostanzialmente nel punto in cui sono allocate e non si verificano nuove scritture per quel file quando ci sono sovrascritture o elimina - ricerca COW e BTRFS ). Invece di creare il file con troncato, crealo con "fallocate -l"

  fallocate -l <size in kilobytes> filename
  chattr +C filename
  

  suggerimento: backup con bsdtar o tar, copia con rsync o cp

l'argomento successivo è EXT thin vs thick luns:

• suole sottili che sono radi

  truncate -s <size in kilobytes> filename
  

  suggerimento: backup con bsdtar , copia con cp

• i lun di spessore sono file regolari con l'attributo + C (+ C in modo che non renda COW, copia su scrittura, in modo che tutte le scritture si attengano essenzialmente al punto in cui sono allocate e non si verificano nuove scritture per quel file quando ci sono sovrascritture o elimina - ricerca COW e BTRFS ). Invece di creare il file con troncato, crealo con "fallocate -l"

  touch filename
  fallocate -l <size in kilobytes> filename
  

  suggerimento: backup con bsdtar o tar, copia con rsync o cp

qual è un file spesso vs sottile

• lun / file spessi, riempiono i loro dati da 0 alla dimensione assegnata, i metadati fingono dove sono gli 0. mentre riempi i dati, i dati si riempiono
• luns / file spessi: riempi i loro dati all'inizio con 0s o qualunque cosa (zero pigro o zero desideroso) - questi impostano le prenotazioni (o come ZFS piace chiamare i rinfreschi)

L'articolo di VMware QUI descrive lazy vs eager zero con luns / file spessi: https://communities.vmware.com/message/2199576

mancia

ricorda che thick and thin non si applicano solo ai Luns, ma anche ai file, ai filesystem zfs (condivisioni / volumi / luns), e sono sicuro di altre cose (basta guardare zfs).

Dalla descrizione del pacchetto Ubuntu ( http://packages.ubuntu.com/de/lucid/bsdtar )

"Il programma bsdtar presenta numerosi vantaggi rispetto alle precedenti implementazioni tar:

• Biblioteca. Poiché la funzionalità principale si trova in una libreria, può essere utilizzata da altri strumenti, come pkg_add.
• Rilevamento automatico del formato. Libarchive rileva automaticamente la compressione (nessuna / gzip / bzip2) e il formato (vecchio tar, ustar, gnutar, pax, cpio, iso9660, zip) durante la lettura degli archivi. Lo fa per qualsiasi fonte di dati.
• Supporto per il formato di interscambio Pax. Questa è un'estensione POSIX / SUSv3 al vecchio formato tar "ustar" che aggiunge attributi estesi arbitrari a ciascuna voce. Fa tutto ciò che fa il formato tar GNU, solo meglio.
• Gestisce flag di file, ACL, nomi di percorso arbitrari, ecc. Il formato di interscambio Pax supporta gli attributi chiave / valore usando una tecnica facilmente estensibile. Percorsi arbitrari, nomi di gruppi, nomi di utenti, dimensioni di file fanno parte dello standard POSIX; libarchive estende questo con il supporto per file flags, ACL e numeri di dispositivo arbitrari.
• Supporto tar GNU. Libarchive legge la maggior parte degli archivi tar GNU. Se c'è domanda, questo può essere ulteriormente migliorato ".

Quello che segue è basato sulla lettura, non sull'esperienza: sto appena iniziando con Freebsd, quindi non ho quasi alcuna esperienza reale (vengo principalmente da Linux). Mi scuso (e sollecito umilmente la correzione) se ho perso qualcosa di importante e quello che dico qui è spazzatura ...

Dalla mia lettura delle pagine del manuale (di recente quella rifatta sopra http://www.freebsd.org/cgi/man.cgi?query=tar&sektion=1 ) il catrame di Freebsd manca del (-d, --diff , --compare) capacità. Ciò non sorprende, dal momento che gli autori di Freebsd dump / restore non sembrano aver fornito nulla del genere.

Non so con certezza se il tar Gnu includerà tutti i metadati UFS come si dice faccia Freebsd tar, e questo è un problema importante. Ma per i miei gusti, non posso MAI considerare il completamento di un dump fino a quando non ho archiviato una somma MD5 del file di output, E POI quindi ho confrontato il file di dump con i dati che presumibilmente ho scaricato. Vari problemi possono portare a dati di dump diversi da quelli presenti sul disco. (Non solo modifiche ai file, ma errori del disco, errori di memoria, guasti della macchina e così via. Tutto ciò mi è effettivamente successo.)

Secondo me, questo rende Gnu tar l'unica opzione che ho trovato finora per creare veri backup su un sistema Freebsd di serie.

Mi piacerebbe molto imparare diversamente, FWIW. Preferirei utilizzare le utilità native almeno per la clonazione delle partizioni e i backup con ripristino di emergenza. Ma se non si riesce a verificare la correttezza di una discarica, non vedo il punto di preoccuparsi di crearne una.

• bsdtar può leggere e tarare i membri provenienti da altri archivi usando la @archivesintassi

• Tar GNU ha l' --deleteopzione - anche se di recente, ho scoperto che potrebbe corrompere l'archivio.