deteksi dan koreksi bit busuk dengan mdadm

Saya akan mengatur ulang semua HDD saya di nas box linux rumah saya dan ingin menggunakan raid mdadm untuk perlindungan data dan fleksibilitasnya untuk membentuk kembali array. Namun, sebelum saya menggunakan mdadm untuk ini, saya ingin tahu bagaimana menangani bit busuk . Khususnya jenis bit busuk yang tidak menghasilkan pesan kesalahan baca yang tidak dapat dipulihkan yang dikirim dari HDD.

Mengingat bahwa saya akan kemungkinan besar akan menggunakan setidaknya 21TB dari HDD di 8 disk di nas dan berbagai kutipan pada probabilitas dari kegagalan pada HDD, aku berpikir bahwa selama membangun kembali dari kegagalan disk tunggal aku cukup mungkin untuk pertemuan beberapa bentuk bit busuk pada disk yang tersisa. Jika ini merupakan kesalahan baca yang tidak dapat dipulihkan pada 1 drive, drive tersebut benar-benar melaporkannya sebagai kesalahan, saya percaya itu seharusnya baik-baik saja dengan raid6 (bukan?). Namun jika data yang dibaca dari disk buruk tetapi tidak dilaporkan oleh disk, maka saya tidak bisa melihat bagaimana ini dapat secara otomatis diperbaiki bahkan dengan raid6. Apakah ini sesuatu yang perlu kita perhatikan? Mengingat artikel Ini adalah 2010 dan RAID5 masih berfungsi, dan pengalaman sukses saya sendiri di rumah dan di tempat kerja, semuanya tidak serta merta seperti kesedihan dan pemasaran yang ingin kita percayai, tetapi saya benci harus memulihkan dari cadangan hanya karena HDD gagal.

Mengingat bahwa pola penggunaannya adalah, tulis paling banyak beberapa kali, dan bacalah sesekali, saya perlu melakukan scrubbing data . Saya melihat di archlinux wiki perintah mdadm untuk data menggosok array

echo check > /sys/block/md0/md/sync_action

kemudian untuk memantau perkembangannya

cat /proc/mdstat

Menurut saya ini akan membaca semua sektor semua disk dan memeriksa apakah data cocok dengan paritas dan sebaliknya. Meskipun saya perhatikan ada penekanan besar dalam dokumen untuk mengatakan bahwa ada keadaan signifikan bahwa operasi "pemeriksaan" tidak akan dapat memperbaiki secara otomatis, hanya mendeteksi, dan akan menyerahkannya kepada pengguna untuk memperbaikinya.

Level mdadm RAID apa yang harus saya pilih untuk memaksimalkan perlindungan saya dari bit busuk dan langkah pemeliharaan serta perlindungan apa yang harus saya lakukan? Dan apa yang tidak akan melindungi saya dari ini?

Sunting: Saya tidak ingin memulai RAID vs ZFS atau QA teknologi lainnya. Saya ingin tahu secara khusus tentang serangan mdadm. Itu juga mengapa saya bertanya tentang Unix & Linux dan bukan pada SuperUser .

Sunting: adalah jawabannya: mdadm hanya dapat memperbaiki URE yang dilaporkan oleh sistem disk selama scrub data dan mendeteksi busuk bit diam selama scrub tetapi tidak dapat / tidak akan memperbaikinya?

Terus terang, saya merasa agak mengejutkan bahwa Anda akan menolak RAIDZ2 ZFS. Tampaknya sesuai dengan kebutuhan Anda hampir dengan sempurna, kecuali kenyataan bahwa itu bukan Linux MD. Saya tidak pada perang salib untuk membawa ZFS ke massa, tetapi fakta sederhana adalah bahwa Anda adalah salah satu jenis masalah yang ZFS dirancang dari bawah ke atas untuk dipecahkan. Mengandalkan RAID (RAID "biasa") apa pun untuk memberikan deteksi dan koreksi kesalahan yang mungkin dalam situasi pengurangan atau tidak ada redundansi tampaknya berisiko. Bahkan dalam situasi di mana ZFS tidak dapat memperbaiki kesalahan data dengan benar, setidaknya dapat mendeteksi kesalahan dan membiarkan Anda tahu bahwa ada masalah, yang memungkinkan Anda untuk mengambil tindakan korektif.

Anda tidak harus melakukan scrub penuh reguler dengan ZFS, meskipun disarankan untuk berlatih. ZFS akan memverifikasi bahwa data yang dibaca dari disk cocok dengan apa yang ditulis sebagai data yang sedang dibaca, dan dalam kasus ketidakcocokan baik (a) menggunakan redundansi untuk merekonstruksi data asli, atau (b) melaporkan kesalahan I / O kepada aplikasi. Juga, menggosok adalah operasi online prioritas rendah, sangat berbeda dari pemeriksaan sistem file di sebagian besar sistem file yang dapat prioritas tinggi dan offline. Jika Anda menjalankan scrub dan sesuatu selain yang ingin dilakukan I / O, scrub akan mengambil kursi belakang selama durasi. Scrub ZFS menggantikan scrub RAID dan metadata dan data sistem file pemeriksaan integritas, jadi jauh lebih menyeluruh daripada hanya menggosok array RAID untuk mendeteksi bit busuk (yang tidak memberi tahu Anda jika data masuk akal sama sekali, hanya saja itu telah ditulis dengan benar oleh pengontrol RAID).

Redundansi ZFS (RAIDZ, mirroring, ...) memiliki keuntungan bahwa lokasi disk yang tidak digunakan tidak perlu diperiksa konsistensi selama scrub; hanya data aktual yang diperiksa selama scrub, saat alat berjalan di rantai blok alokasi. Ini sama dengan kolam non-redundan. Untuk RAID "biasa", semua data (termasuk lokasi yang tidak digunakan pada disk) harus diperiksa karena pengontrol RAID (apakah perangkat keras atau perangkat lunak) tidak tahu data apa yang sebenarnya relevan.

Dengan menggunakan RAIDZ2 vdevs, setiap dua drive konstituen dapat gagal sebelum Anda berisiko kehilangan data aktual dari kegagalan drive lain, karena Anda memiliki redundansi senilai dua drive. Ini pada dasarnya sama dengan RAID6.

Di ZFS semua data, baik data pengguna dan metadata, adalah checksummed (kecuali jika Anda memilih untuk tidak melakukannya, tetapi itu direkomendasikan terhadap), dan checksum ini digunakan untuk mengonfirmasi bahwa data tidak berubah karena alasan apa pun. Sekali lagi, jika sebuah checksum tidak sesuai dengan nilai yang diharapkan, data akan direkonstruksi secara transparan atau kesalahan I / O akan dilaporkan. Jika kesalahan I / O dilaporkan, atau scrub mengidentifikasi file dengan korupsi, Anda akan mengetahui fakta bahwa data dalam file tersebut berpotensi rusak dan dapat memulihkan file tertentu dari cadangan; tidak perlu untuk mengembalikan array penuh.

RAID, bahkan paritas ganda, RAID tidak melindungi Anda terhadap situasi seperti misalnya ketika satu drive gagal dan satu lagi membaca data dengan tidak benar dari disk. Misalkan satu drive gagal dan ada sedikit flip di mana saja dari salah satu drive lain: tiba-tiba, Anda memiliki korupsi yang tidak terdeteksi, dan kecuali Anda senang dengan itu Anda akan memerlukan cara untuk setidaknya mendeteksinya. Cara untuk mengurangi risiko itu adalah dengan memeriksa setiap blok pada disk dan memastikan checksum tersebut tidak dapat rusak bersama dengan data (melindungi terhadap kesalahan seperti penulisan lalat, menulis yatim, menulis ke lokasi yang salah pada disk, dll.), Yang persis apa yang dilakukan ZFS selama checksumming diaktifkan.

Satu-satunya downside nyata adalah bahwa Anda tidak dapat dengan mudah mengembangkan vdev RAIDZ dengan menambahkan perangkat ke dalamnya. Ada solusi untuk itu, biasanya melibatkan hal-hal seperti file jarang sebagai perangkat dalam vdev, dan sangat sering disebut "Saya tidak akan melakukan ini jika itu data saya". Oleh karena itu, jika Anda menggunakan rute RAIDZ (terlepas dari apakah Anda menggunakan RAIDZ, RAIDZ2 atau RAIDZ3), Anda harus memutuskan di muka berapa banyak drive yang Anda inginkan di setiap vdev. Meskipun jumlah drive di vdev sudah diperbaiki, Anda dapat menumbuhkan vdev secara bertahap (memastikan untuk tetap dalam ambang redundansi vdev) mengganti drive dengan yang berkapasitas lebih besar dan memungkinkan resilver lengkap.

Jawaban ini adalah produk penalaran berdasarkan berbagai bukti yang saya temukan. Saya tidak tahu bagaimana implementasi kernel Linux bekerja, karena saya bukan dev kernel dan tampaknya ada banyak informasi yang salah masuk akal di luar sana. Saya berasumsi bahwa kernel Linux membuat pilihan yang waras. Jawaban saya harus berlaku kecuali saya salah.

Banyak drive menggunakan ECC (kode koreksi kesalahan) untuk mendeteksi kesalahan baca. Jika data rusak, kernel akan menerima URE (kesalahan baca yang tidak dapat dipulihkan) untuk blok itu dari drive pendukung ECC. Dalam keadaan ini (dan ada pengecualian di bawah ini), menyalin data yang rusak, atau kosong, atas data yang baik akan menjadi gila. Dalam situasi ini kernel harus mengetahui data mana yang baik dan mana yang merupakan data buruk. Menurut artikel Ini adalah 2010 dan RAID5 masih berfungsi ... :

Pertimbangkan alternatif ini, yang saya tahu harus digunakan oleh setidaknya beberapa vendor array. Ketika sebuah drive dalam volume RAID melaporkan URE, pengontrol array menambah hitungan dan memenuhi I / O dengan membangun kembali blok dari paritas. Kemudian melakukan penulisan ulang pada disk yang melaporkan URE (berpotensi dengan verifikasi) dan jika sektor ini buruk, mikrokode akan memetakan kembali dan semuanya akan baik-baik saja.

Namun, sekarang sebagai pengecualian: jika drive tidak mendukung ECC, drive berbohong tentang korupsi data, atau firmware sangat tidak berfungsi, maka URE mungkin tidak dilaporkan, dan data yang rusak akan diberikan ke kernel. Dalam kasus ketidakcocokan data: tampaknya jika Anda menggunakan 2 disk RAID1, atau RAID5, maka kernel tidak dapat mengetahui data mana yang benar, bahkan ketika dalam keadaan tidak terdegradasi, karena hanya ada satu paritas memblokir dan tidak ada URE yang dilaporkan. Dalam disk1 RAID1 3 atau RAID6, satu blok yang ditandai non-URE yang rusak tidak akan cocok dengan paritas redundan (dalam kombinasi dengan blok terkait lainnya), sehingga pemulihan otomatis yang tepat harus dimungkinkan.

Moral dari cerita ini adalah: gunakan drive dengan ECC. Sayangnya tidak semua drive yang mendukung ECC mengiklankan fitur ini. Di sisi lain, berhati-hatilah: Saya kenal seseorang yang menggunakan SSD murah dalam 2 disk RAID1 (atau 2 copy RAID10). Salah satu drive mengembalikan data acak yang rusak pada setiap pembacaan sektor tertentu. Data yang rusak disalin secara otomatis ke data yang benar. Jika SSD menggunakan ECC, dan berfungsi dengan baik, maka kernel seharusnya mengambil tindakan korektif yang tepat.

Untuk perlindungan yang Anda inginkan, saya akan menggunakan RAID6 + cadangan luar biasa di 2 lokasi.

Saya pribadi menggosok seminggu sekali, dan cadangan setiap malam, mingguan dan bulanan tergantung pada data penting dan kecepatan perubahan.

Saya tidak punya cukup perwakilan untuk berkomentar, tetapi saya ingin menunjukkan bahwa sistem mdadm di Linux TIDAK memperbaiki kesalahan. Jika Anda mengatakannya untuk "memperbaiki" kesalahan selama scrub, katakanlah, RAID6, jika ada ketidakkonsistenan, itu akan "memperbaikinya" dengan mengasumsikan bagian data benar dan menghitung ulang paritas.

sedikit busuk fud.? Tentu...

Saya kira Anda perlu berbicara dengan SEAGATE. (lupa? Apakah itu alasannya)? drive sekarang semua memiliki koreksi ECC 100bit Anda harus membuktikan busuk pertama.
Saya yakin Anda tidak bisa. (Ini hal yang FUD untuk dikhawatirkan, bukan?) seperti takut pada hantu atau yang ke-13? dan tidak dilakukan di sini. tidak ada bukti yang terjadi. dan lebih buruk tidak ada bukti penyebabnya.

Pertama, tentukan apa arti bit busuk.? Aduh ... HDD: ECC memeriksa data (bahkan 1 bit) terhadap penyimpanan ECC 100 bit. jika salah, itu memperbaikinya, jika terus gagal mesin SMART, pasti pada drive SAS, itu secara logis menggantikan cluster atau sektor dengan yang baik. menggunakan cluster cadangan. ini memperbaiki kerusakan. Ya semua drive menumbuhkan bit buruk dari hari pertama hingga akhir, dari drive pertama IBM ke SEKARANG. tapi sekarang kami melakukan perbaikan sendiri, Baca laporan lengkap Seagate. tak ada habisnya, dan belajar bagaimana drive bekerja. baik?

ini terus berlangsung sampai Anda kehabisan suku cadang, (otak hdd, pintar) dan kemudian SMART menjerit AKHIR HIDUP. (atau bahkan lebih awal, seperti HP) pada pengontrol HP P420, ia mengawasi ini setiap saat. Milik saya email saya, menunjukkan DEKAT DARI cluster SPARE. Kadang-kadang suku cadang melaju lebih cepat, pertanda pasti akan segera berakhir, (10 tahun juga, kurang di sata rongsokan.

Saya memanggil BOGUS, dan FUD pada bit busuk.

Dugaan saya adalah seseorang yang membuat PC salah menuliskan data, untuk alasan apa pun. tidak menjalankan memori ECC ?? oops, server sebenarnya memiliki ECC RAM. terinfeksi virus.? atau kehilangan daya selama penulisan (tidak ada UPS>?)? atau memiliki memori buruk.? atau ESD rusak. Atau PSU membuat banyak kebisingan (buruk)

Saya memanggil FUD di sini. Maaf,