Apakah bit busuk pada hard drive adalah masalah nyata? Apa yang bisa dilakukan?


32

Seorang teman berbicara dengan saya tentang masalah bit busuk - bit pada drive membalik secara acak, merusak data. Sangat jarang, tetapi dengan waktu yang cukup itu bisa menjadi masalah, dan tidak mungkin dideteksi.

Drive tidak akan menganggapnya sebagai sektor yang buruk, dan cadangan hanya akan berpikir file telah berubah. Tidak ada checksum yang terlibat untuk memvalidasi integritas. Bahkan dalam pengaturan RAID, perbedaannya akan terdeteksi tetapi tidak akan ada cara untuk mengetahui salinan cermin mana yang benar.

Apakah ini masalah nyata? Dan jika demikian, apa yang bisa dilakukan untuk itu? Teman saya merekomendasikan zfs sebagai solusi, tetapi saya tidak bisa membayangkan meratakan server file kami di tempat kerja, memakai Solaris dan zfs ..



Saya baru saja mengalami kesalahan SMART yang bagus pada disk Seagate 200GB yang lama. Bit, mereka telah membusuk terlalu banyak :-( Ini enam bulan pendek dari garansi 5 tahun, jadi saya mungkin akan mendapatkan penggantian tanpa banyak rewel.
ThatGraemeGuy

Jawaban:


24

Pertama: Sistem file Anda mungkin tidak memiliki checksum, tetapi hard drive Anda sendiri memilikinya. Ada SMART, misalnya. Sekali terlalu banyak dibalik, kesalahan tidak bisa diperbaiki, tentu saja. Dan jika Anda benar-benar beruntung, bit dapat berubah sedemikian rupa sehingga checksum tidak akan menjadi tidak valid; maka kesalahan bahkan tidak akan terdeteksi. Jadi, hal-hal buruk bisa terjadi; tetapi klaim bahwa membalik sedikit acak akan langsung merusak data Anda adalah palsu.

Namun, ya, ketika Anda meletakkan triliunan bit pada hard drive, mereka tidak akan tetap seperti itu selamanya; itu masalah nyata! ZFS dapat melakukan pemeriksaan integritas setiap kali data dibaca; ini mirip dengan apa yang sudah dilakukan oleh hard drive Anda sendiri, tetapi ini merupakan pengamanan lain untuk Anda yang mengorbankan sebagian ruang, sehingga Anda meningkatkan ketahanan terhadap korupsi data.

Ketika sistem file Anda cukup baik, kemungkinan kesalahan terjadi tanpa terdeteksi menjadi sangat rendah sehingga Anda tidak perlu peduli tentang itu lagi dan Anda mungkin memutuskan bahwa memiliki checksum yang dibangun ke dalam format penyimpanan data yang Anda gunakan adalah tidak perlu.

Either way: tidak, itu tidak mungkin untuk dideteksi .

Tetapi sistem file, dengan sendirinya, tidak pernah bisa menjadi jaminan bahwa setiap kegagalan dapat dipulihkan dari; itu bukan peluru perak. Anda masih harus memiliki cadangan dan rencana / algoritma untuk apa yang harus dilakukan ketika kesalahan telah terdeteksi.


Ok, menurut wikipedia ( en.wikipedia.org/wiki/Error_detection_and_correction ) hard drive modern menggunakan CRC untuk mendeteksi kesalahan dan mencoba memulihkan menggunakan pemulihan kesalahan gaya disk kompak. Itu cukup baik untukku.
scobi

1
Tetapi jika CRC disimpan di lokasi (sektor) yang sama dengan data, ini tidak akan membantu untuk semua kasus kesalahan. Misal jika ada data kesalahan penentuan posisi kepala dapat ditulis ke sektor yang salah - tetapi dengan checksum yang benar => Anda tidak akan dapat mendeteksi masalah. Itu sebabnya checksum di ZFS disimpan secara terpisah dari data yang mereka lindungi.
knweiss

Apakah ZFS memiliki pemeliharaan seperti yang dimiliki Windows sekarang? Itu pada dasarnya menulis ulang data secara teratur untuk menyegarkan pengkodean magnetik.
TomTom

Hard drive modern tidak menggunakan CRC, mereka menggunakan kode Hamming yang sangat berbeda. Itu adalah hal yang sama yang menggunakan memori ECC. Kesalahan flip satu bit dapat diperbaiki, kesalahan flip dua bit dapat dideteksi tetapi tidak diperbaiki, tiga atau lebih bit membalik dan data sebenarnya rusak. Dalam hal apa pun, tidak ada pengganti untuk cadangan data. ZFS dan sistem file lainnya tidak memberikan perlindungan yang lebih baik daripada kode Hamming pada piringan drive. Jika data rusak maka ZFS tidak akan menyelamatkan Anda.
Jody Lee Bruchon

@JodyLeeBruchon Anda punya sumber kode Hamming yang digunakan terutama sekarang? Pengumpulan info apa yang telah saya lakukan belakangan ini mengindikasikan bahwa pembuat drive masih menggunakan CRC-RS. 1 2
Ian Schoonover

16

Ya itu masalah, terutama karena ukuran drive naik. Sebagian besar drive SATA memiliki tingkat URE (kesalahan pembacaan yang tidak dapat diperbaiki) sebesar 10 ^ 14. Atau untuk setiap 12TB data yang dibaca secara statistik, vendor drive mengatakan drive akan mengembalikan pembacaan gagal (Anda biasanya dapat melihatnya pada lembar spesifikasi drive). Drive akan terus berfungsi dengan baik untuk semua bagian drive lainnya. Drive Enterprise FC & SCSI umumnya memiliki tingkat URE 10 ^ 15 (120TB) bersama dengan sejumlah kecil drive SATA yang membantu menguranginya.

Saya tidak pernah melihat disk berhenti berputar pada waktu yang sama, tetapi saya telah mengalami volume serangan raid5 masalah ini (5 tahun yang lalu dengan drive PATA konsumen 5400RPM). Drive gagal, itu ditandai mati dan terjadi pembangunan kembali ke drive cadangan. Masalahnya adalah bahwa selama pembangunan kembali drive kedua tidak dapat membaca satu blok data kecil itu. Bergantung pada siapa yang melakukan penggerebekan, seluruh volume mungkin mati atau hanya blok kecil itu yang mungkin mati. Dengan asumsi hanya satu blok yang mati, jika Anda mencoba membacanya Anda akan mendapatkan kesalahan tetapi jika Anda menulisnya, drive akan memetakannya kembali ke lokasi lain.

Ada beberapa metode yang harus dilindungi: raid6 (atau yang setara) yang melindungi terhadap kegagalan disk ganda adalah yang terbaik, yang lainnya adalah filesystem sadar URE seperti ZFS, menggunakan grup raid yang lebih kecil sehingga secara statistik Anda memiliki peluang lebih kecil untuk menabrak drive URE batas (mirror drive besar atau drive raid5 lebih kecil), scrubbing disk & SMART juga membantu tetapi tidak benar-benar perlindungan itu sendiri tetapi digunakan sebagai tambahan untuk salah satu metode di atas.

Saya mengelola hampir 3000 spindle di array, dan array terus-menerus menggosok drive mencari URE laten. Dan saya menerima aliran yang cukup konstan dari mereka (setiap kali menemukan itu memperbaikinya sebelum kegagalan drive dan mengingatkan saya), jika saya menggunakan raid5 bukan raid6 dan salah satu drive benar-benar mati ... Saya akan akan bermasalah jika menghantam lokasi tertentu.


2
Unit apa yang Anda pakai? "10 ^ 14" bukan "tingkat".
Jay Sullivan

2
Unit akan misalnya "10 ^ 14 bit dibaca per kesalahan", yang sama dengan 12 TB dibaca per kesalahan.
Jo Liss

2
Dan tentu saja, perlu diingat bahwa tingkat kesalahan biasanya dikutip dalam hal kesalahan sektor penuh per bit dibaca. Jadi ketika pabrikan menyatakan tingkat URE pada 10 ^ -14, yang sebenarnya mereka maksudkan adalah bahwa probabilitas setiap sektor acak membaca mengenai URE adalah 10 ^ -14 dan jika ya, maka seluruh sektor kembali menjadi tidak terbaca. Itu dan fakta bahwa ini adalah statistik; di dunia nyata, URE cenderung datang dalam kelompok.
CVn

9

Hard drive umumnya tidak mengkodekan bit data sebagai domain magnetik tunggal - produsen hard drive selalu menyadari bahwa domain magnetik dapat membalik, dan membangun deteksi kesalahan dan koreksi ke drive.

Jika sedikit terbalik, drive berisi cukup data yang berlebihan yang dapat dan akan diperbaiki pada saat sektor tersebut dibaca. Anda dapat melihat ini jika Anda memeriksa statistik SMART pada drive, sebagai 'Tingkat kesalahan yang dapat diperbaiki'.

Tergantung pada detail drive, itu bahkan harus dapat pulih dari lebih dari satu bit yang terbalik di suatu sektor. Akan ada batas jumlah bit yang dibalik yang dapat dikoreksi secara diam-diam, dan mungkin batas lain untuk jumlah bit yang dibalik yang dapat dideteksi sebagai kesalahan (bahkan jika tidak ada lagi data yang cukup andal untuk memperbaikinya)

Ini semua menambahkan fakta bahwa hard drive dapat secara otomatis memperbaiki sebagian besar kesalahan saat terjadi, dan dapat diandalkan untuk mendeteksi sebagian besar sisanya. Anda harus memiliki sejumlah besar kesalahan bit dalam satu sektor, bahwa semua terjadi sebelum sektor itu dibaca lagi, dan kesalahan tersebut harus sedemikian rupa sehingga kode deteksi kesalahan internal melihatnya sebagai data yang valid lagi, sebelum Anda akan pernah mengalami kegagalan diam. Itu bukan tidak mungkin, dan saya yakin bahwa perusahaan yang mengoperasikan pusat data yang sangat besar melihat itu terjadi (atau lebih tepatnya, itu terjadi dan mereka tidak melihat itu terjadi), tetapi tentu saja itu bukan masalah besar seperti yang mungkin Anda pikirkan.


2
Sebenarnya, saya secara teratur memiliki kesalahan bit-rot (di bagian saya tidak membaca banyak), yang sistem pulih dari diam-diam (salah). Jika setidaknya itu memberi tahu saya ada bit-rot, saya bisa membaca kembali data untuk memulihkannya sebelum menjadi tidak dapat dipulihkan; dan jika tidak dapat dipulihkan, saya dapat membandingkannya dengan hard drive lain.
Alex

Alex, silakan periksa data HDD SMART Anda, dan sistem RAM untuk memverifikasi tidak ada masalah lain yang menyebabkan korupsi. Busuk bit / korupsi acak sangat jarang, jadi mungkin ada hal lain yang terjadi dengan mesin Anda.
Brian D.

@BrianD. Satu masalah adalah, saya menyimpan hard drive di dalam bahan pengepakan (terisolasi) mereka; ini menyebabkan hard drive memanas lebih dari 60 ° C saat bekerja, selama berhari-hari. Apakah itu terdengar seperti alasan yang sah mengapa bit busuk mungkin terjadi?
Alex

Ini jelas tidak dianjurkan, karena sebagian besar HDD memiliki lubang udara kecil di dalamnya yang tidak boleh ditutup untuk beroperasi dengan benar. Apakah masalah Anda sedikit-busuk atau sesuatu yang lain, saya akan menjalankan diagnostik penuh pada PC untuk memverifikasi semuanya berfungsi dengan benar.
Brian D.

4

Hard drive modern (sejak 199x) tidak hanya memiliki checksum tetapi juga ECC, yang dapat mendeteksi dan memperbaiki sedikit bit bit "acak". Lihat: http://en.wikipedia.org/wiki/SMART .

Di sisi lain, bug tertentu dalam firmware dan driver perangkat juga dapat merusak data pada kesempatan yang jarang (jika tidak QA akan menangkap bug) yang akan sulit dideteksi jika Anda tidak memiliki checksum level yang lebih tinggi. Driver perangkat awal untuk SATA dan NIC memiliki data yang rusak pada Linux dan Solaris.

ZFS checksum sebagian besar bertujuan untuk bug di perangkat lunak tingkat rendah. Sistem penyimpanan / basis data yang lebih baru seperti Hypertable juga memiliki checksum untuk setiap pembaruan untuk melindungi dari bug di sistem file :)


3

Secara teoritis, ini memprihatinkan. Secara praktis, ini adalah bagian dari alasan kami menyimpan cadangan anak / orang tua / kakek nenek. Cadangan tahunan harus disimpan setidaknya selama 5 tahun, IMO, dan jika Anda memiliki kasus ini akan kembali lebih jauh dari itu, file tersebut jelas tidak terlalu penting.

Kecuali jika Anda berurusan dengan bit yang berpotensi mencairkan otak seseorang , saya tidak yakin risiko vs hadiah cukup sampai mengubah sistem file.


1
Saya tidak melihat bagaimana cadangan anak / orang tua / kakek nenek membantu. Tidak ada cara untuk mengetahui dengan sistem itu jika sedikit dibalik karena pengguna bermaksud mengubahnya atau jika drive melakukannya sendiri. Bukan tanpa semacam checksum.
scobi

Memiliki banyak cadangan tidak akan membantu jika Anda tidak tahu bahwa data di dalamnya baik. Anda dapat secara manual memeriksa file Anda, tetapi ZFS melakukannya jauh lebih otomatis dan membuat manajemen sistem file menjadi mudah.
Amok

1
Memiliki cadangan yang kembali lebih dari satu minggu / bulan meningkatkan peluang Anda untuk memiliki salinan file yang baik. Saya mungkin bisa lebih jelas tentang itu.
Kara Marfia

1
Masalahnya adalah: bagaimana Anda tahu Anda memiliki salinan yang buruk? Dan bagaimana Anda tahu salinan mana yang didukung adalah yang baik? Secara otomatis.
scobi

Saya telah melihat mungkin satu file setiap beberapa tahun jatuh ke korupsi yang mungkin akibat dari sedikit membusuk, tetapi saya mungkin menderita Sindrom Ikan Kecil. Saya bisa mengerti pembicaraan tentang cadangan menjadi tidak berguna, dan saya akan menghapusnya jika itu menyinggung. Sudah waktunya dihabiskan membaca jawaban lain, terlepas dari. ;)
Kara Marfia

2

Ya itu masalah.

Ini adalah salah satu alasan mengapa RAID6 sekarang dalam mode (serta meningkatkan ukuran HD meningkatkan waktu untuk membangun kembali sebuah array). Memiliki dua blok paritas memungkinkan untuk cadangan tambahan.

Sistem RAID sekarang juga melakukan Penggosokan RAID yang secara berkala membaca blok disk, memeriksa paritas, dan menggantinya jika menemukan blok menjadi buruk.


Hati-hati, integritas data bukan fitur semua sistem RAID.
duffbeer703

1
Dengan drive terabyte, ada begitu banyak bit yang berbagi nasib, dan area penyimpanan fisik yang sedikit sangat kecil, sehingga masalah ini menjadi lebih penting. Pada saat yang sama, probabilitas kegagalan meningkat sangat banyak dengan drive terabyte sehingga RAID6 tidak cukup kecuali Anda meletakkan banyak drive di kolam, katakan 8 atau lebih. Dengan jumlah drive yang lebih kecil, lebih baik menggunakan strip mirror alias RAID 10. Baik RAID 6 (raidz2) dan RAID 10 (zpool membuat mirror mypool c0t1d0 c0t2d0 mirror c0t3d0 c0t4d0) dimungkinkan di ZFS.
Michael Dillon

RAID tidak dapat menentukan data mana yang baik dan mana yang tidak sehingga tidak dapat memperbaiki kesalahan, hanya bisa mendeteksi mereka.
Amok

Amuck: Bukan sebagai bagian dari "Standar RAID", per se, tetapi sistem RAID canggih (firmware, dll.) Melakukannya
Matt Rogish

@ Michael Dillion - Keandalan RAID6 tidak meningkat saat Anda menambah jumlah drive. Untuk semua data hanya ada data asli + 2 paritas. Meningkatkan jumlah drive lebih buruk untuk keandalan karena meningkatkan kemungkinan tingkat kegagalan drive tanpa meningkatkan redundansi data apa pun. Satu-satunya alasan untuk menambah nomor drive, adalah untuk menambah ukuran penyimpanan Anda.
Brian D.

1

Sehubungan dengan pernyataan OP tentang RAID tidak memahami data apa yang baik vs buruk.

Pengontrol RAID menggunakan paling tidak, bit paritas (ganjil / genap) pada setiap strip data. Ini untuk segalanya; strip data-on-disk dan strip data paritas (cadangan).

Ini berarti bahwa untuk semua tipe RAID yang memiliki striping untuk redundansi (RAID 5/6) controller dapat secara akurat mengetahui apakah strip data asli telah berubah, dan juga, jika strip data redundansi telah berubah.

Jika Anda memperkenalkan strip redundan kedua seperti RAID6, Anda harus memiliki 3 strip data, pada tiga drive yang berbeda menjadi rusak, yang semuanya sesuai dengan data file aktual yang sama. Ingat bahwa sebagian besar sistem RAID menggunakan strip data yang relatif kecil (128 kb atau kurang) sehingga kemungkinan "bit busuk" berbaris ke 128kb yang sama, dari file yang sama, praktis tidak mungkin.


0

Ini masalah dunia nyata, ya, tapi pertanyaannya adalah apakah Anda harus khawatir atau tidak.

Jika Anda hanya mendapatkan gambar penuh hdd, itu mungkin tidak sepadan. Ini penuh dengan data ilmiah penting, mungkin itu jenis cerita lain, Anda tahu.

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.