Kita semua khawatir tentang menjaga data dan file kita aman dan utuh, tetapi apakah mungkin data menjadi rusak dan diakses oleh pengguna tanpa pemberitahuan atau peringatan tentang masalah apa pun? Posting SuperUser Q & A saat ini memiliki jawaban untuk pertanyaan pembaca yang khawatir.
Sesi Tanya & Jawab hari ini hadir untuk memberi kami hak milik SuperUser-sub divisi Stack Exchange, pengelompokan situs web Q & A berbasis komunitas.
Foto milik generalising (Flickr).
Pembaca SuperUser topo morto ingin tahu apakah data pada hard drive dapat menurunkan dan diakses tanpa peringatan tentang kerusakan:
Apakah mungkin degradasi fisik hard drive dapat menyebabkan bit-bit “flip” dalam isi file tanpa sistem operasi memperhatikan perubahan dan memberi tahu pengguna tentang hal itu ketika membaca file? Misalnya, dapatkah "p" (biner 01110000) dalam file teks ASCII berubah menjadi "q" (biner 01110001), lalu ketika pengguna membuka file, mereka melihat "q" tanpa menyadari bahwa telah terjadi kegagalan?
Saya tertarik pada jawaban yang berkaitan dengan FAT, NTFS, atau ReFS (jika itu membuat perbedaan). Saya ingin tahu apakah sistem operasi melindungi pengguna dari ini, atau jika kita harus memeriksa data kami untuk variasi antara salinan dari waktu ke waktu.
Dapatkah data pada hard drive menurun dan diakses tanpa peringatan tentang kerusakan?
Kontributor SuperUser Guntram Blohm memiliki jawabannya untuk kami:
Ya, ada sesuatu yang disebut bit busuk. Tapi tidak, itu tidak akan mempengaruhi pengguna tanpa disadari.
Ketika hard drive menulis sektor ke piringan, itu tidak hanya menulis bit dengan cara yang sama seperti mereka disimpan dalam RAM, ia menggunakan pengkodean untuk memastikan tidak ada urutan dari bit yang sama yang terlalu panjang. Ia juga menambahkan kode ECC yang memungkinkan untuk memperbaiki kesalahan yang mempengaruhi beberapa bit dan mendeteksi kesalahan yang mempengaruhi lebih dari beberapa bit.
Ketika hard drive membaca sektor ini, ia akan memeriksa kode ECC ini dan memperbaiki data jika perlu (dan jika mungkin). Apa yang terjadi selanjutnya tergantung pada keadaan dan firmware hard drive, yang dipengaruhi oleh penunjukan drive.
- Jika suatu sektor dapat dibaca dan tidak memiliki masalah kode ECC, maka diteruskan ke sistem operasi.
- Jika suatu sektor dapat diperbaiki dengan mudah, versi yang diperbaiki dapat ditulis ke disk, dibaca kembali, kemudian diverifikasi untuk menentukan apakah kesalahan itu acak (yaitu sinar kosmik, dll) atau jika ada kesalahan sistematis dengan media.
- Jika hard drive menentukan bahwa ada kesalahan dengan media, ia akan mengalokasikan ulang sektor ini.
- Jika suatu sektor tidak dapat dibaca atau dikoreksi setelah beberapa upaya baca (pada hard drive yang ditetapkan sebagai RAID hard drive), maka hard drive akan menyerah, realokasi sektor, dan memberi tahu pengontrol bahwa ada masalah . Ini bergantung pada kontroler RAID untuk merekonstruksi sektor dari anggota RAID lainnya dan menulisnya kembali ke hard drive yang gagal, yang kemudian menyimpannya di sektor yang dialokasikan (yang semoga tidak memiliki masalah).
- Jika suatu sektor tidak dapat dibaca atau dikoreksi pada hard drive desktop, maka hard drive akan melakukan lebih banyak upaya untuk membacanya. Tergantung pada kualitas hard drive, ini mungkin melibatkan reposisi kepala, memeriksa untuk melihat apakah ada bit yang membalik ketika membaca berulang kali, memeriksa bit mana yang paling lemah, dan beberapa hal lainnya. Jika salah satu dari upaya ini berhasil, hard drive akan merealokasi sektor dan menulis kembali data yang diperbaiki.
Ini adalah salah satu perbedaan utama antara hard drive yang dijual sebagai hard drive "desktop", "NAS / RAID", atau "pengawasan video". Hard drive RAID dapat dengan cepat menyerah dan membuat pengontrol memperbaiki sektor untuk menghindari latensi di sisi pengguna. Hard drive desktop akan terus mencoba lagi dan lagi karena membiarkan pengguna menunggu beberapa detik mungkin lebih baik daripada memberi tahu mereka bahwa data hilang. Dan video hard drive nilai data rate konstan lebih dari pemulihan kesalahan sebagai bingkai yang rusak biasanya tidak akan diperhatikan.
Bagaimanapun, hard drive akan tahu jika ada sedikit membusuk, biasanya akan pulih dari itu, dan jika tidak bisa, akan memberitahu controller yang pada gilirannya akan memberitahu driver yang kemudian akan memberitahu sistem operasi. Kemudian, terserah sistem operasi untuk menyajikan kesalahan kepada pengguna dan bertindak di atasnya. Inilah sebabnya mengapa cybernard mengatakan:
- Saya tidak pernah menyaksikan satu kesalahan pun, tetapi saya telah melihat banyak hard drive di mana seluruh sektor telah gagal.
Hard drive akan tahu jika ada sesuatu yang salah dengan sektor, tetapi tidak akan tahu bit mana yang gagal. Satu bit yang gagal akan selalu tertangkap oleh ECC.
Harap dicatat bahwa chkdsk dan sistem file yang secara otomatis memperbaiki diri tidak menangani perbaikan data dalam file. Ini ditargetkan pada korupsi dalam struktur sistem file itu sendiri, seperti perbedaan dalam ukuran file antara entri direktori dan jumlah blok yang dialokasikan. Fitur penyembuhan diri NTFS akan mendeteksi kerusakan struktural dan mencegahnya dari mempengaruhi data Anda lebih lanjut, tetapi tidak akan memperbaiki data yang sudah rusak.
Tentu saja ada alasan lain mengapa data bisa menjadi rusak. Misalnya, RAM buruk pada pengontrol dapat mengubah data sebelum dikirim ke hard drive. Dalam hal ini, tidak ada mekanisme pada hard drive yang akan mendeteksi atau memperbaiki data, dan ini mungkin menjadi salah satu alasan mengapa struktur sistem file rusak.Alasan lain termasuk bug perangkat lunak, pemadaman saat menulis ke hard drive (meskipun ini ditangani oleh journal sistem file), atau driver sistem file yang buruk (driver NTFS di Linux gagal membaca-hanya untuk waktu yang lama sejak NTFS direkayasa terbalik, tidak didokumentasikan, dan pengembang tidak mempercayai kode mereka sendiri).
- Saya memiliki skenario ini sekali di mana aplikasi akan menyimpan semua file ke dua server yang berbeda di dua pusat data yang berbeda untuk menjaga copy pekerjaan dari data yang tersedia dalam semua keadaan. Setelah beberapa bulan, kami melihat bahwa sekitar 0,1 persen dari semua file yang disalin tidak cocok dengan jumlah cek MD5 yang disimpan aplikasi dalam database-nya. Ternyata kabel serat yang salah antara server dan SAN.
Alasan lain ini adalah mengapa beberapa sistem file, seperti ZFS, menyimpan informasi cek tambahan untuk mendeteksi kesalahan. Mereka dirancang untuk melindungi Anda dari lebih banyak hal yang bisa salah daripada hanya sedikit membusuk.
Memiliki sesuatu untuk ditambahkan ke penjelasan? Bicaralah di komentar. Ingin membaca lebih banyak jawaban dari pengguna Stack Exchange yang paham teknologi lainnya? Lihat diskusi lengkap di sini.
