Hapus 10 juta file + dari ZFS, secara efektif

Saya telah menulis program kereta yang secara tidak sengaja membuat sekitar 30 juta file di bawah / tmp. (Bug diperkenalkan beberapa minggu yang lalu, dan itu membuat beberapa subdirektori per detik.) Saya bisa mengganti nama / tmp ke / tmp2, dan sekarang saya harus menghapus file. Sistemnya adalah FreeBSD 10, sistem file root adalah zfs.

Sementara itu salah satu drive di cermin salah, dan saya telah menggantinya. Drive ini memiliki dua disk SSD 120GB.

Inilah pertanyaannya: mengganti hard drive dan memasang kembali seluruh array membutuhkan waktu kurang dari satu jam. Menghapus file / tmp2 adalah cerita lain. Saya telah menulis program lain untuk menghapus file, dan hanya dapat menghapus 30-70 subdirektori per detik. Diperlukan 2-4 hari untuk menghapus semua file.

Bagaimana mungkin resilver seluruh array membutuhkan waktu satu jam, tetapi menghapus dari disk membutuhkan waktu 4 hari? Mengapa kinerja saya sangat buruk? 70 penghapusan / detik nampaknya performanya sangat sangat buruk.

Saya bisa menghapus inode untuk / tmp2 secara manual, tetapi itu tidak akan membebaskan ruang, kan?

Mungkinkah ini masalah dengan zfs, atau hard drive atau apa?

Menghapus ZFS itu mahal. Terlebih lagi jika Anda mengaktifkan deduplikasi pada sistem file (karena file deduped dereferencing mahal). Snapshots juga dapat memperumit masalah.

Anda mungkin lebih baik menghapus /tmpdirektori daripada data yang terkandung di dalamnya.

Jika /tmpmerupakan sistem file ZFS, hapus dan buat kembali.

Bagaimana mungkin resilver seluruh array membutuhkan waktu satu jam, tetapi menghapus dari disk membutuhkan waktu 4 hari?

Pertimbangkan sebuah gedung kantor.

Menghapus semua komputer dan furnitur dan barang-barang dari semua kantor di semua lantai membutuhkan waktu lama , tetapi meninggalkan kantor segera dapat digunakan oleh klien lain.

Menghancurkan seluruh bangunan dengan RDX adalah seluruh banyak lebih cepat, tetapi klien berikutnya adalah cukup mungkin untuk mengeluh tentang bagaimana berangin tempat ini.

Ada beberapa hal yang terjadi di sini.

Pertama, semua teknologi disk modern dioptimalkan untuk transfer massal. Jika Anda perlu memindahkan 100MB data, mereka akan melakukannya lebih cepat jika mereka berada di satu blok yang berdekatan daripada tersebar di semua tempat. SSD sangat membantu di sini, tetapi bahkan mereka lebih suka data dalam blok yang berdekatan.

Kedua, resilver cukup optimal sejauh operasi disk berjalan. Anda membaca sepotong besar data yang berdekatan dari satu disk, melakukan beberapa operasi CPU cepat di atasnya, kemudian menulis ulang di sepotong besar yang berdekatan ke disk lain. Jika listrik gagal setengah jalan, bukan masalah besar - Anda hanya akan mengabaikan data dengan checksum yang buruk dan melanjutkan seperti biasa.

Ketiga, menghapus file sangat lambat . ZFS sangat buruk, tetapi secara praktis semua sistem file lambat untuk dihapus. Mereka harus memodifikasi sejumlah besar potongan data yang berbeda pada disk dan mengatur waktu dengan benar (yaitu menunggu) sehingga sistem file tidak rusak jika daya gagal.

Bagaimana mungkin resilver seluruh array membutuhkan waktu satu jam, tetapi menghapus dari disk membutuhkan waktu 4 hari?

Resilver adalah sesuatu yang membuat disk sangat cepat, dan penghapusan adalah sesuatu yang lambat pada disk. Per megabyte disk, Anda hanya perlu melakukan sedikit resilver. Anda mungkin memiliki seribu file di ruang itu yang perlu dihapus.

70 penghapusan / detik nampaknya performanya sangat sangat buruk

Tergantung. Saya tidak akan terkejut dengan ini. Anda belum menyebutkan jenis SSD apa yang Anda gunakan. Intel modern dan SSD Samsung cukup bagus dalam operasi semacam ini (baca-modifikasi-tulis) dan akan berkinerja lebih baik. SSD yang lebih murah / lebih lama (mis. Corsair) akan lambat. Jumlah operasi I / O per detik (IOPS) adalah faktor penentu di sini.

ZFS adalah sangat lambat untuk menghapus hal-hal. Biasanya, itu akan melakukan penghapusan di latar belakang sehingga Anda tidak melihat penundaan. Jika Anda melakukan sejumlah besar dari mereka itu tidak dapat menyembunyikannya dan harus menunda Anda.

Lampiran: mengapa penghapusan lambat?

• Menghapus file memerlukan beberapa langkah. Metadata file harus ditandai sebagai 'dihapus', dan akhirnya harus direklamasi sehingga ruang dapat digunakan kembali. ZFS adalah 'filesystem terstruktur log' yang berkinerja terbaik jika Anda hanya pernah membuat sesuatu, tidak pernah menghapusnya. Struktur log berarti bahwa jika Anda menghapus sesuatu, ada celah di log dan data lain harus disusun ulang (didefragmentasi) untuk mengisi kesenjangan. Ini tidak terlihat oleh pengguna tetapi umumnya lambat.
• Perubahan harus dibuat sedemikian rupa sehingga jika daya gagal sebagian, sistem file tetap konsisten. Seringkali, ini berarti menunggu hingga disk mengonfirmasi bahwa data benar-benar ada di media; untuk SSD, itu bisa memakan waktu lama (ratusan milidetik). Efek bersih dari ini adalah bahwa ada lebih banyak pembukuan (yaitu operasi disk I / O).
• Semua perubahan itu kecil. Alih-alih membaca, menulis, dan menghapus seluruh blok flash (atau silinder untuk disk magnetik), Anda perlu memodifikasi sedikit. Untuk melakukan ini, perangkat keras harus membaca di seluruh blok atau silinder, memodifikasinya dalam memori, kemudian menuliskannya ke media lagi. Ini butuh waktu lama.

Bagaimana mungkin resilver seluruh array membutuhkan waktu satu jam, tetapi menghapus dari disk membutuhkan waktu 4 hari?

Ini dimungkinkan karena dua operasi bekerja pada lapisan yang berbeda dari tumpukan sistem file. Resilver dapat menjalankan level rendah dan sebenarnya tidak perlu melihat file individual, menyalin sebagian besar data sekaligus.

Mengapa kinerja saya sangat buruk? 70 penghapusan / detik nampaknya performanya sangat sangat buruk.

Itu memang harus melakukan banyak pembukuan ...

Saya bisa menghapus inode untuk / tmp2 secara manual, tetapi itu tidak akan membebaskan ruang, kan?

Saya tidak tahu untuk ZFS, tetapi jika bisa secara otomatis pulih dari itu, kemungkinan besar, pada akhirnya, melakukan operasi yang sama yang sudah Anda lakukan, di latar belakang.

Mungkinkah ini masalah dengan zfs, atau hard drive atau apa?

Apakah zfs scrubmengatakan sesuatu?

Menghapus banyak file tidak pernah benar-benar operasi yang cepat.

Untuk menghapus file pada sistem file apa pun , Anda perlu membaca indeks file, menghapus (atau menandai sebagai dihapus) entri file dalam indeks, menghapus metadata lain yang terkait dengan file, dan menandai ruang yang dialokasikan untuk file tersebut sebagai tidak digunakan. Ini harus dilakukan secara terpisah untuk setiap file yang akan dihapus, yang berarti menghapus banyak file memerlukan banyak I / Os kecil. Untuk melakukan ini dengan cara yang memastikan integritas data jika terjadi kegagalan daya, menambah biaya tambahan.

Bahkan tanpa kekhasan yang diperkenalkan ZFS, menghapus 30 juta file biasanya berarti lebih dari seratus juta operasi I / O yang terpisah. Ini akan memakan waktu lama bahkan dengan SSD yang cepat. Seperti yang telah disebutkan orang lain, desain ZFS semakin menambah masalah ini.

Ian Howson memberikan jawaban yang bagus mengapa lambat.

Jika Anda menghapus file secara paralel, Anda mungkin melihat peningkatan kecepatan karena penghapusan dapat menggunakan blok yang sama dan dengan demikian dapat menyimpan penulisan ulang blok yang sama berkali-kali.

Jadi cobalah:

find /tmp -print0 | parallel -j100 -0 -n100 rm

dan lihat apakah kinerjanya lebih baik daripada 70 penghapusan Anda per detik.

Sangat sederhana jika Anda membalikkan pemikiran Anda.

1. Dapatkan drive kedua (sepertinya Anda sudah memilikinya)

2. Salin semuanya dari drive A ke drive B dengan rsync, tidak termasuk direktori / tmp. Rsync akan lebih lambat daripada salinan blok.

3. Reboot, menggunakan drive B sebagai volume boot baru

4. Memformat ulang drive A.

Ini juga akan mendefrag drive Anda dan memberi Anda direktori baru (baik, defrag tidak begitu penting dengan SSD tetapi membuat linierisasi file Anda tidak akan menyakiti apa pun)

Anda memiliki 30 juta entri dalam daftar yang tidak disortir. Anda memindai daftar untuk entri yang ingin Anda hapus dan Anda menghapusnya. Sekarang Anda hanya memiliki 29.999.999 entri dalam daftar Anda yang tidak disortir. Jika semuanya ada di / tmp, mengapa tidak reboot saja?

Diedit untuk mencerminkan informasi dalam komentar: Pernyataan masalah: Menghapus sebagian besar, tetapi tidak semua , dari 30M + file yang dibuat secara salah di / tmp membutuhkan waktu lama.
Masalah 1) Cara terbaik untuk menghapus banyak file yang tidak diinginkan dari / tmp.
Masalah 2) Memahami mengapa sangat lambat untuk menghapus file.

Solusi 1) - / tmp diatur ulang ke kosong saat boot oleh sebagian besar * distribusi nix. Namun FreeBSD, bukan salah satunya.
Langkah 1 - menyalin file menarik di tempat lain.
Langkah 2 - Sebagai root

 $ grep -i tmp /etc/rc.conf  
 clear_tmp_enable="YES" # Clear /tmp at startup.  

Langkah 3 - reboot.
Langkah 4 - ubah clear_tmp_enable kembali ke "Tidak".
File yang tidak diinginkan sekarang hilang karena ZFS di FreeBSD memiliki fitur bahwa "Menghancurkan sebuah dataset jauh lebih cepat daripada menghapus semua file yang berada pada dataset, karena tidak melibatkan pemindaian semua file dan memperbarui semua metadata yang sesuai. " jadi yang harus dilakukan saat boot adalah mengatur ulang metadata untuk dataset / tmp. Ini sangat cepat.

Solusi 2) Mengapa sangat lambat? ZFS adalah sistem file luar biasa yang mencakup fitur seperti akses direktori waktu konstan. Ini bekerja dengan baik jika Anda tahu apa yang Anda lakukan, tetapi bukti menunjukkan bahwa OP bukan ahli ZFS. OP belum mengindikasikan bagaimana mereka mencoba untuk menghapus file, tetapi pada tebakan, saya akan mengatakan mereka menggunakan variasi pada "find regex -exec rm {} \;". Ini bekerja dengan baik dengan angka kecil tetapi tidak skala karena ada tiga operasi serial terjadi 1) dapatkan daftar file yang tersedia (mengembalikan 30 juta file dalam urutan hash), 2) menggunakan regex untuk memilih file berikutnya yang akan dihapus, 3 ) beri tahu OS untuk menemukan dan menghapus file itu dari daftar 30 juta. Bahkan jika ZFS mengembalikan daftar dari memori dan jika cache 'find', regex masih harus mengidentifikasi file berikutnya yang akan diproses dari daftar dan kemudian memberitahu OS untuk memperbarui metadata untuk mencerminkan perubahan itu dan kemudian memperbarui daftar sehingga tidak diproses lagi.