Apa perbedaan antara tar bsdtar dan GNU?


46

Saya selalu menggunakan GNU tar. Namun, semua distribusi GNU / Linux yang pernah saya lihat dikirimkan bsdtardalam repositori mereka. Saya bahkan telah melihatnya diinstal secara default di beberapa, IIRC. Saya tahu pasti bahwa Arch GNU / Linux memerlukannya sebagai bagian dari basedevel(mungkin base, tapi saya tidak yakin), seperti yang saya lihat di PKGBUILDs.

Mengapa Anda ingin menggunakan bsdtarbukannya GNU tar? Apa kelebihannya?

Perhatikan bahwa saya adalah orang yang bertanya Apa perbedaan utama antara pengguna BSD dan GNU / Linux? .


Jawaban:


29

Ubuntu bsdtarsebenarnya adalah implementasi tar yang dibundel dengan libarchive; dan itu harus dibedakan dari klasik bsdtar. Beberapa varian BSD digunakan libarchiveuntuk implementasi tar mereka, misalnya FreeBSD.

GNUtartidak mendukung varian tar lainnya dan deteksi kompresi otomatis.

Ketika visualisasi menyisipkan uraian dari Ubuntu, ada beberapa hal di sana yang khusus untuk libarchive:

  1. libarchiveadalah definisi perpustakaan, dan berbeda dari klasik bsdtardan GNUtardengan cara itu.
  2. libarchive tidak dapat membaca beberapa variasi tar GNU lama yang tidak jelas, yang paling terkenal adalah pengkodean beberapa header di base64, sehingga file tar akan menjadi ASCII 7-bit yang bersih (ini merupakan kasus untuk 1.13.6-1.13.11 dan diubah pada 1.13.12 , kode itu hanya resmi tar selama 2 minggu)
  3. libarchive's bsdtarakan membaca file non-tar (misalnya zip, iso9660, cpio), tapi bsdtar klasik tidak akan.

Sekarang kita sudah libarchivekeluar dari jalan, sebagian besar turun ke apa yang didukung dalam klasik bsdtar.

Anda dapat melihat sendiri halaman manual di sini:

Dalam pertanyaan awal Anda, Anda bertanya apa kelebihan klasik itu bsdtar, dan saya tidak yakin benar-benar ada. Satu-satunya waktu yang paling penting adalah jika Anda mencoba menulis skrip shell yang perlu bekerja pada semua sistem; Anda perlu memastikan apa yang Anda sampaikan tarsebenarnya valid di semua varian.

GNUtar, libarchive's bsdtar, klasik bsdtar, stardan BusyBox' s tartentu saja implementasi tar yang akan Anda temui sebagian besar waktu, tapi saya yakin ada orang lain di luar sana (QNX awal misalnya). libarchive/ GNUtar/ staradalah yang paling penuh fitur, tetapi dalam banyak hal mereka telah lama menyimpang dari standar aslinya (mungkin menjadi lebih baik).


15

BSDTAR vs TAR plus banyak lagi

Ini satu manfaatnya !!

Saya akan masuk ke 5 topik di sini (dan pergi jauh dari topik, tetapi akan mencakup apa yang Anda inginkan juga):

  1. bsdtar vs tar
  2. file jarang vs tidak
  3. file tebal dan tipis / roti dengan btrfs
  4. file tebal dan tipis / roti tanpa btrfs
  5. bedakan antara tebal dan tipis dan bagaimana itu tidak berlaku hanya untuk roti

bsdtar menangani file jarang lebih baik daripada tar biasa

  • bsdtar akan mengambil semua nol dan hanya metadata saja
  • tar akan benar-benar memproses setiap nol

* contoh: bayangkan file sparse 20 tb (disebut biglun) dengan 10 MB data di seluruh sparsefile 20 tb (biglun) ... sekarang karena ini adalah file jarang, hanya perlu 10 MB pada drive.

Cara membuat file jarang:

File Jarang - cara membuatnya - mendeteksinya - semuanya File Jarang adalah seperti roti "tipis" (jika Anda menggunakannya untuk roti). roti "tebal" akan menjadi cerita yang berbeda.

* kembali ke topik:

  • menaiki biglun akan membuat tar melewati semua 10 MB bersama dengan semua ~ 20tb lebih buruk dari nol yang tersebar di seluruh lun ... itu akan memakan waktu yang saya duga, dan file tar akan cukup besar. Juga - mengekstraksi - Saya belum pernah melakukan ekstrak file tar dari file jarang, tetapi mungkin tidak cantik; Saya mungkin salah di sini.

  • bsdtarring biglun hanya akan memproses 10 MB data, dan membuat metadata kecil untuk ~ 20tb nol.

Manfaat? Yah banyak dari mereka; Saya baru saja menulis beberapa di atas.

Ini mirip dengan rsync vs cp

  • Juga, jika Anda rsync file jarang raksasa, itu akan berperilaku seperti tar
  • Jika Anda cp file raksasa, itu akan berperilaku secara otomatis seperti bsdtar (Anda dapat mengubah perilaku cp untuk pergi ke nol, atau tidak pergi ke nol)

Secara pribadi, saya suka membayangkan file jarang seperti roti tipis, dan file biasa seperti roti tebal ...

Topik selanjutnya adalah BTRFS thin vs thick luns:

  • Dengan filesystem seperti BTRFS , lun yang tipis adalah file yang jarang (buat dengan truncate, seperti pada dokumen wiki).

     truncate -s <size in kilobytes> filename
    

    tip: cadangan dengan bsdtar , salin dengan cp

  • lun tebal adalah file biasa dengan atribut + C (+ C sehingga membuatnya tidak ada SAP, salin di tulis, sehingga semua menulis pada dasarnya tetap berada di tempat itu dialokasikan, dan tidak ada tulisan baru terjadi untuk file itu ketika ada overwrite atau menghapus - penelitian KK dan btrfs ). Alih-alih membuat file dengan truncate, buatlah dengan "fallocate -l"

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

    tip: cadangan dengan bsdtar atau tar, salin dengan rsync atau cp

Topik berikutnya adalah EXT thin vs luns thick:

  • roti tipis yang jarang

    truncate -s <size in kilobytes> filename
    

    tip: cadangan dengan bsdtar , salin dengan cp

  • lun tebal adalah file biasa dengan atribut + C (+ C sehingga membuatnya tidak ada SAP, salin di tulis, sehingga semua dasarnya menulis tetap di mana dialokasikan, dan tidak ada menulis baru terjadi untuk file itu ketika ada overwrite atau menghapus - penelitian KK dan btrfs ). Alih-alih membuat file dengan truncate, buatlah dengan "fallocate -l"

    touch filename
    fallocate -l <size in kilobytes> filename
    

    tip: cadangan dengan bsdtar atau tar, salin dengan rsync atau cp

apa file tebal vs tipis

  • lun / file tebal, isi data mereka dari 0 hingga ukuran yang ditentukan, metadata berpura-pura di mana 0s berada. saat Anda mengisi data, data terisi
  • lun / file tebal: isi data mereka di awal dengan 0s atau apa pun (nol malas atau nol bersemangat) - ini mengatur pemesanan (atau seperti ZFS ingin memanggil refreservations)

VMWARE ARTICLE HERE menjelaskan malas vs bersemangat nol dengan lun / file tebal: https://communities.vmware.com/message/2199576

tip

ingat tebal dan tipis tidak hanya berlaku untuk luns, itu juga bisa di file, zfs filesystems (share / volume / luns), dan saya yakin hal-hal lain (lihat saja zfs).


1
Bagus dan teliti. Selamat datang di situs ...
eyoung100

1
- Jarang dengan tar apa pun: Hanya meneruskan -S ke sebagian besar implementasi tar, mereka semua telah mendukungnya untuk waktu yang lama. - Jarang dengan rsync: sekali lagi, lewati --sparse, berfungsi. Kelemahan dari menggunakan deteksi jarang adalah bahwa alat tersebut harus benar-benar membaca blok lebih banyak, yang dapat memperkenalkan banyak CPU (terutama dalam kasus bolak nol / non-nol berjalan).
robbat2

Masih lebih baik menggunakan bsdtar, meskipun gnu tar mendukung flag sparse, karena bsdtar tahu cara melompati lubang jarang, tanpa memprosesnya (mis. Jika Anda memiliki file jarang 1 TB dengan hanya 1k data, bsdtar akan memproses 1k dari data. Gnu tar akan memproses 1TB.
moveaway00

13

Dari deskripsi paket Ubuntu ( http://packages.ubuntu.com/de/lucid/bsdtar )

"Program bsdtar memiliki sejumlah keunggulan dibandingkan implementasi tar sebelumnya:

  • Perpustakaan. Karena fungsionalitas inti ada di pustaka, ini dapat digunakan oleh alat lain, seperti pkg_add.
  • Deteksi format otomatis. Libarchive secara otomatis mendeteksi kompresi (none / gzip / bzip2) dan format (tar lama, ustar, gnutar, pax, cpio, iso9660, zip) saat membaca arsip. Ini melakukan ini untuk sumber data apa pun.
  • Dukungan Format Interchange Pax. Ini adalah ekstensi POSIX / SUSv3 ke format tar "ustar" lama yang menambahkan atribut diperluas secara acak ke setiap entri. Melakukan semua yang dilakukan oleh format tar GNU, hanya lebih baik.
  • Menangani flag file, ACL, nama path arbitrer, dll. Format pertukaran pax mendukung atribut kunci / nilai menggunakan teknik yang mudah diperluas. Nama path yang sewenang-wenang, nama grup, nama pengguna, ukuran file adalah bagian dari standar POSIX; libarchive memperluas ini dengan dukungan untuk flag file, ACL, dan nomor perangkat yang berubah-ubah.
  • Dukungan tar GNU. Libarchive membaca sebagian besar arsip tar GNU. Jika ada permintaan, ini bisa diperbaiki lebih lanjut. "

1

Berikut ini didasarkan pada membaca, bukan pengalaman - Saya baru memulai dengan Freebsd jadi saya hampir tidak memiliki pengalaman nyata dengannya (saya berasal dari kebanyakan Linux). Saya minta maaf (dan dengan rendah hati meminta koreksi) jika saya melewatkan sesuatu yang penting dan apa yang saya katakan di sini adalah sampah ...

Dari pembacaan saya pada halaman buku panduan (paling baru satu referensi di atas http://www.freebsd.org/cgi/man.cgi?query=tar&sektion=1 ) tar Freebsd tidak memiliki (-d, --diff , --compare) kemampuan. Ini tidak mengherankan, karena penulis Freebsd dump / restore tampaknya tidak menyediakan yang seperti ini juga.

Saya tidak tahu pasti apakah Gnu tar akan menggabungkan semua metadata UFS seperti yang dikatakan Freebsd tar lakukan, dan ini merupakan masalah penting. Tetapi untuk selera saya, saya TIDAK PERNAH mempertimbangkan dump untuk diselesaikan sampai saya telah menyimpan jumlah MD5 dari file output, DAN KEMUDIAN membandingkan file dump dengan data yang baru saja saya duga dibuang. Berbagai masalah dapat menyebabkan data yang dibuang berbeda dari apa yang ada di disk. (Bukan hanya perubahan file, tetapi kesalahan disk, kesalahan memori, kesalahan mesin, dan sebagainya. Semua yang sebenarnya terjadi pada saya.)

Menurut pendapat saya sendiri, ini menjadikan Gnu tar satu-satunya pilihan yang sejauh ini saya temukan untuk membuat backup yang benar pada sistem Freebsd saham.

Saya ingin sekali belajar sebaliknya, FWIW. Saya lebih suka menggunakan utilitas asli setidaknya untuk kloning partisi dan cadangan pemulihan sulit. Tetapi jika seseorang tidak dapat memverifikasi kebenaran dump, saya tidak melihat gunanya repot untuk membuatnya.


1
  • bsdtar dapat membaca dan tar anggota yang datang dari arsip lain menggunakan @archivesintaks

  • GNU tar memiliki --deletepilihan - meskipun baru-baru, saya menemukan bahwa bahwa itu dapat merusak arsip.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.