Mengapa rm lambat pada drive penyimpanan eksternal (terhubung-USB, ketik fuseblk) dengan 50Gb file?

21

Saya telah mencoba menggunakan rsnapshot untuk membuat cadangan, tetapi saya merasa itu tidak dapat digunakan. Meskipun ia dapat melakukan diff direktori (50gb) dan menduplikatnya (menghubungkan setiap file) dalam beberapa menit, dan saya dapat cp seluruh direktori dalam waktu sekitar setengah jam, dibutuhkan lebih dari satu jam untuk menghapusnya. Bahkan secara langsung menggunakan rm -rfv, saya menemukan itu bisa memakan waktu hingga setengah detik untuk rm file tunggal, sedangkan cpdan linkperintah selesai secara instan.

Mengapa rm begitu lambat? Apakah ada cara yang lebih cepat untuk menghapus hardlink secara rekursif? Tidak masuk akal bagi saya bahwa menyalin file seharusnya lebih cepat daripada menghapusnya.

Filesystem yang sedang saya kerjakan adalah drive penyimpanan eksternal, terhubung melalui usb dan ketik fuseblk (yang menurut saya artinya adalah ntfs). Komputer saya menjalankan linux ubuntu.

Output dari atas:

Cpu(s):  3.0%us,  1.5%sy,  0.0%ni, 54.8%id, 40.6%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:   8063700k total,  3602416k used,  4461284k free,   557604k buffers

performance rm external-hdd

— Benubird
sumber

1

Sedang dipasang fuseblkbukan berarti drive tersebut adalah NTFS, itu hanya berarti ia dipasang sebagai perangkat blok FUSE. Itu bisa hampir apa saja.

— Chris Down

1

@ ChrisDown Benar, tapi saya tahu itu NTFS atau ext3, dan saya cukup yakin apakah itu ext3 itu akan di-mount dengan mount tanpa argumen.

— Benubird

1

Itu tergantung berapa banyak file dalam direktori (Anda tidak mengatakan berapa), dan khususnya NTFS melambat dengan hanya> 3K file dalam direktori. Cukup banyak setiap sistem file lainnya jauh lebih performant. Lihat semua posting lainnya di SO / SE tentang pengaruh jumlah file pada kinerja sistem file.

— smci

28

Pada akhirnya, apa pun yang Anda lakukan, rmharus dijalankan unlinkpada setiap file yang ingin Anda hapus (bahkan jika Anda memanggil rm -rdirektori induk). Jika ada banyak file untuk dihapus, ini bisa memakan waktu lama.

Ada dua proses yang sangat memakan waktu ketika Anda menjalankan rm -r:

readdir, diikuti oleh,
sejumlah panggilan ke unlink.

Menemukan semua file, dan kemudian melalui setiap file untuk menghapusnya, dapat memakan waktu yang sangat, sangat lama.

Jika Anda menemukan ini "tidak dapat digunakan" karena membuat direktori tidak dapat digunakan untuk beberapa waktu, pertimbangkan untuk memindahkan direktori induk sebelum menghapusnya. Ini akan membebaskan nama itu agar program dapat digunakan kembali, tanpa waktu yang terlalu merepotkan.

Dengan asumsi bahwa sistem file benar - benar NTFS (tidak jelas dari pertanyaan Anda), NTFS umumnya cukup lambat dalam menghapus petak besar file. Anda mungkin mempertimbangkan untuk menggunakan filesystem yang lebih cocok untuk keperluan Anda (filesystem ext yang lebih baru memiliki kinerja penghapusan yang cukup bagus, jika Anda tidak memiliki kebutuhan khusus lainnya). FUSE itu sendiri juga tidak terlalu cepat, secara umum. Anda mungkin mempertimbangkan untuk melihat apakah Anda dapat melakukan ini dengan cara yang tidak menggunakan FUSE.

— Chris Down
sumber

2

+1 Benar-benar banyak tergantung pada sistem file yang tepat - banyak yang cenderung berkinerja sangat baik untuk beberapa operasi sementara lamban dengan yang lain (seringkali ini untuk pembuatan file vs penghapusan vs akses data).

— peterph

15

Mengapa rm begitu lambat? Saya tidak punya ide. Tapi saya tahu cara yang lebih cepat:

mkdir blank
rsync -a --delete blank/ test/

Pembaruan: Jawaban pada Serverfault ini memiliki beberapa penjelasan. Sepertinya rsync menghapus file dalam urutan tertentu yang menyebabkan pohon sistem file tetap seimbang, dan tidak pernah perlu penyeimbangan ulang. rm hanya akan menghapus file dan menyebabkan banyak penyeimbangan kembali saat dihapus. Ada beberapa informasi tentang penyeimbangan ulang di sini .

— rjmunro
sumber

1

Sudahkah Anda membandingkan dan membandingkan ini rm -rf? rsyncmasih memiliki unlink()semua file di test/, dan mungkin itulah yang membutuhkan waktu.

— MattBianco

Saya belum secara resmi membandingkannya, tetapi saya mencobanya setelah membaca tolok ukur orang lain, dan perbedaannya sangat besar. Saya tidak dapat menemukan posting itu lagi, tetapi jawaban di serverfault ini memiliki penjelasan dan sumber untuk program penghapusan yang lebih cepat.

— rjmunro

Tetapi metode tercepat harus ada unlink(2)di direktori (dan ingat untuk melakukannya fscknanti) ...

— MattBianco

Fakta adalah fakta. Hanya menghitung waktunya, dan hampir dua kali lebih cepat. Setelah membaca GNU coreutils rm code, itu bahkan tidak membuat saya bertanya-tanya ...

— Dominik George

1

Yah, saya pernah punya masalah yang sama dengan Anda. Saya menemukan bahwa "wa" Anda tinggi, bisa Anda gunakan

iostat -x 1

untuk memeriksa apakah utilisasi disk Anda tinggi, jika demikian, itu berarti disk Anda cukup sibuk. Periksa apakah ada proses lain yang menulis ke disk terus menerus.

Untuk kemudahan, gunakan

vmstat 1

untuk memeriksa apakah b tinggi atau r < b . Itu menunjukkan sesuatu yang salah. Dalam situasi Anda, saya pikir disk io adalah alasan asli.

— fibonacci
sumber