alternatif yang lebih cepat untuk cp -a


9

Untuk transfer sederhana / home ke disk lain saya menggunakan cp -ayang menurut saya cara yang sangat lambat. Seharusnya tahu cara yang lebih efisien untuk menyelesaikan tugas. Saya memiliki / home mount sebagai volume logis, tetapi disk target bukan sistem LVM


4
Jika cplambat, metode lain juga akan lambat. Kecuali jika itu bukan penyalinan berorientasi file
daisy

Cobalah untuk mendiagnosis kemacetan Anda, itu tergantung pada pengaturan khusus Anda. Anda mungkin ingin mencoba noatimeopsi mount untuk mengurangi penulisan yang tidak perlu, khususnya ke sistem file sumber.
Elias Torres Arroyo

Jawaban:


16

Coba tar, pax, cpio, dengan sesuatu buffering.

(cd /home && bsdtar cf - .) |
  pv -trab -B 500M |
  (cd /dest && bsdtar xpSf -)

Saya menyarankan bsdtaralih-alih tarkarena setidaknya pada beberapa distribusi Linux taradalah GNU tar yang bertentangan dengan bsdtar(dari libarchive) tidak menangani pelestarian atribut yang diperluas atau ACL atau atribut linux.

pvakan buffer hingga 500 juta data sehingga dapat mengakomodasi fluktuasi kecepatan baca dan tulis pada kedua sistem file dengan lebih baik (meskipun dalam kenyataannya, Anda mungkin akan memiliki disk yang lebih lambat sehingga yang lain dan mekanisme penulisan kembali OS akan melakukan buffering sebagai baik jadi itu mungkin tidak akan membuat banyak perbedaan). Versi lama yang pvtidak mendukung -a(untuk pelaporan kecepatan rata-rata), Anda dapat menggunakannya pv -B 200Msendirian di sana.

Bagaimanapun, mereka tidak akan memiliki batasan cp, yang membaca dan menulis secara berurutan. Di sini kita punya dua yang tarbekerja bersamaan, sehingga yang satu dapat membaca satu FS sementara yang lain sibuk menunggu FS yang lain selesai menulis.

Untuk ext4 dan jika Anda menyalin ke partisi yang setidaknya sama besar dengan sumbernya, lihat juga clone2fsyang berfungsi ntfsclone, yaitu menyalin blok yang dialokasikan saja dan secara berurutan, jadi pada penyimpanan rotasi mungkin akan menjadi yang paling efisien.

partclone menggeneralisasikan itu ke beberapa sistem file yang berbeda.

Sekarang beberapa hal yang perlu dipertimbangkan ketika kloning sistem file.

Kloning akan menyalin semua direktori, file dan isinya ... dan yang lainnya. Sekarang segalanya berbeda dari sistem file ke sistem file. Bahkan jika kita hanya mempertimbangkan fitur umum dari sistem file Unix tradisional, kita harus mempertimbangkan:

  • tautan: tautan simbolik dan tautan keras. Terkadang, kita harus mempertimbangkan apa yang harus dilakukan dengan symlink absolut atau symlink yang menunjukkan sistem file / direktori untuk dikloning
  • modifikasi terakhir, akses dan waktu perubahan: hanya dua yang pertama yang dapat disalin menggunakan API sistem file (cp, tar, rsync ...)
  • sparseness: Anda mendapatkan file jarang 2TB yang merupakan disk image VM yang hanya membutuhkan 3GB ruang disk, sisanya jarang, melakukan salinan naif akan mengisi drive tujuan.

Kemudian jika Anda mempertimbangkan ext4dan sebagian besar sistem file Linux, Anda harus mempertimbangkan:

  • ACL dan atribut diperluas lainnya (seperti yang digunakan untuk SELinux)
  • Atribut Linux seperti flag immutable atau append-only

Tidak semua alat mendukung semua itu, atau ketika mereka melakukannya, Anda harus mengaktifkannya secara eksplisit seperti --sparse, --acls... opsi rsync, tar... Dan ketika menyalin ke sistem file yang berbeda, Anda harus mempertimbangkan kasus di mana mereka tidak mendukung set fitur yang sama.

Anda mungkin juga harus mempertimbangkan atribut sistem file itu sendiri seperti UUID, ruang yang disediakan untuk root, frekuensi fsck, perilaku penjurnalan, format direktori ...

Lalu ada sistem file yang lebih kompleks, di mana Anda tidak dapat benar-benar menyalin data dengan menyalin file. Pertimbangkan misalnya zfsatau btrfsketika Anda dapat mengambil snapshot dari subvolume dan cabut mereka ... Mereka akan memiliki alat khusus mereka sendiri untuk menyalin data.

Salinan byte ke byte perangkat blok (atau setidaknya blok yang dialokasikan bila memungkinkan) sering kali paling aman jika Anda ingin memastikan bahwa Anda menyalin semuanya. Namun waspadalah terhadap masalah bentrokan UUID, dan itu menyiratkan Anda menyalin ke sesuatu yang lebih besar (meskipun Anda dapat mengubah ukuran salinan snapshot dari sumber sebelum menyalin).


1
GNU tar memiliki --aclsopsi, untuk menyimpan ACL ke dalam arsip. Dan saya akan terkejut jika alat alien (sejenisnya) bsdtarmenanganinya lebih baik daripada yang asli (pada dasarnya) ...
vonbrand

@vonbrand. Tar Anda pasti telah ditambal untuk itu (saya pikir RedHat memiliki patch untuk GNU tar untuk ACL), karena versi terbaru dari GNU tar tidak mendukung opsi seperti itu. Ada ada sejumlah implementasi taruntuk Linux ( star, bsdtar, tar), saya tidak menyadari bahwa GNU tar adalah lebih baik daripada yang lain. Pilihan untuk alat GNU umumnya lebih politis daripada teknis (lihat misalnya bash).
Stéphane Chazelas

1
Menggunakan alat-alat GNU mungkin merupakan pilihan politis, tetapi itu adalah pilihan default. Dan karena mereka jauh lebih populer daripada alternatif, ada juga lebih banyak tenaga pengembang (dan lainnya) di belakang mereka.
vonbrand

terima kasih, waktu berikutnya saya akan menggunakan pv dan tar daripada cp
Yurij73

@ StéphaneChazelas Saat ini GNU tar tidak mendukung--acls
Ploni

4

Saya merekomendasikan rsync, misalnya:

rsync -av --progress --stats dest orig

Atau, untuk mentransfer dengan kompresi:

rsync -avz --progress --stats dest orig

1
rsyncumumnya jauh lebih lambat daripada cpatautar|tar
Stéphane Chazelas

Terima kasih atas informasi ini :) tetapi saya tidak pernah membandingkan keduanya ...
Victor Aurélio


Saya tidak akan terlalu mempercayai artikel itu. Saya menggunakan rsync cukup sering dan salinan biasa pada 130-170 MB / detik.
laebshade

9
rsyncsebagian besar efisien adalah Anda sudah memiliki sebagian sumber data tersedia pada volume tujuan karena hanya akan mentransfer data yang hilang / diubah. Saya tidak akan menggunakannya untuk "salinan pertama" yang cepat.
Totor
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.