Mengapa hard drive yang rusak membekukan seluruh sistem?

128

Mengapa hard drive yang diketahui memiliki blok buruk (diverifikasi dalam HDTune dan HDDScan), membeku di seluruh sistem saya?

Ini bukan drive OS; terpasang ke port SATA lain, dan saya mencoba untuk menyalin file dari itu ke drive lain yang sehat.

Saya telah mengalami masalah ini dengan hampir setiap hard drive yang rusak dan setiap PC Windows.

Saya berharap untuk melihat pembekuan hanya untuk program yang saya gunakan untuk menyalin file (Windows Explorer, dll), tetapi sebaliknya seluruh PC saya tersentak-sentak, dan saya tidak dapat menelusuri web atau menonton film sambil menyalin file dari drive yang rusak.

Ceritanya panjang.

Saya tinggal di daerah pedesaan di mana ada masalah dengan listrik (brownout, dll.). Saya sendiri menggunakan UPS dan hard drive saya sendiri baik-baik saja. Tetapi tetangga saya sering meminta bantuan dengan masalah PC mereka, dan saya sering menemukan bahwa hard drive mereka rusak, kemungkinan besar karena masalah listrik. Tentu saja, setelah mengganti drive yang rusak saya sarankan tetangga saya untuk membeli UPS.

Saya selalu bertanya-tanya, mengapa PC saya membeku sepenuhnya saat mengambil data dari drive yang rusak. Apakah ini masalah perangkat keras? Apakah ini disebabkan oleh cara OS membaca data? Apakah ini sesuatu yang spesifik untuk Windows, dan saya tidak akan mengalaminya di * nix?

Bagaimanapun, mulai sekarang saya akan menggunakan beberapa perangkat lunak khusus (seperti Roadkil's Unstoppable Copier) alih-alih Windows Explorer, walaupun saya tidak yakin apakah ini akan bekerja secara berbeda, tanpa membekukan seluruh PC.

Itu bukan permintaan bantuan, itu lebih untuk tujuan pendidikan, jadi saya tahu mengapa semuanya berjalan seperti itu.

JustAMartin
sumber
11
Menggunakan penutup USB eksternal akan membantu, karena Anda tidak lagi mengikat disk yang rusak ke pengontrol SATA sistem Anda (juga, menambahkan lapisan tambahan perangkat keras yang dapat dikorbankan antara motherboard Anda dan disk yang rusak selalu merupakan ide yang baik).
Matteo Italia
3
Ini tidak khusus untuk SATA, drive IDE melakukan ini juga. Juga hanya karena disk rusak bukan berarti pengontrol tidak, terutama jika ada kesalahan listrik pada disk.
Chris H
Jawaban yang diterima luar biasa, dan berisi apa yang akan saya katakan dan banyak lagi. Pada dasarnya Anda panik dengan pengontrol SATA Anda, yang merupakan perangkat sistem yang sangat penting, yang pada gilirannya membuat panik Windows. Saya bertanya-tanya apakah mengaktifkan AHCI / "hot-swap" di BIOS akan memperbaiki situasi.
Arthur Kay

Jawaban:

170

Ini adalah salah satu area di mana SATA tidak optimal. Masalahnya adalah pada tingkat protokol antarkoneksi perangkat penyimpanan, dan dengan demikian tidak terkait dengan perangkat lunak apa yang Anda jalankan. Menggunakan mesin fotokopi lain atau sistem operasi lain tidak akan secara ajaib membuat segalanya lebih baik, kecuali bahwa itu mungkin mencoba untuk menetapkan nilai batas waktu yang berbeda untuk mengurangi dampak dari masalah (yang mungkin atau mungkin tidak mungkin tergantung pada perangkat keras dan firmware; lihat di bawah ini ).

Ada beberapa poin penting di sini:

  1. Dengan SATA, jika drive berhenti merespons, ini dapat mengikat seluruh sistem penyimpanan, bukan hanya satu drive yang mengalami masalah. Ini tentu memiliki potensi untuk mengikat seluruh pengontrol, dan karena sebagian besar sistem konsumen hanya memiliki pengontrol disk tunggal (yang terintegrasi pada motherboard), ini berarti semua penyimpanan. Lebih buruk lagi jika drive gagal dalam beberapa cara yang tidak standar dan / atau tidak terduga, yang tentunya dapat terjadi jika drive tersebut marjinal. Anda mungkin tertarik dalam Bagaimana disk tunggal di perangkat keras SATA RAID-10 array dapat membuat seluruh array berhenti melengking? pada Kesalahan Server.
  2. Sebagian besar drive SATA konsumen memiliki periode batas waktu default yang lama (sesuai urutan menit) dan banyak drive SATA konsumen tidak memiliki kontrol pemulihan kesalahan yang dapat dikonfigurasi . Apa yang disebut drive "NAS" sering memiliki ERC yang dapat dikonfigurasi, dan drive high-end hampir selalu melakukannya; drive tersebut mungkin juga memiliki batas waktu default lebih pendek (7 detik menjadi nilai umum). Periode waktu tunggu yang lama menguntungkan jika drive memegang satu-satunya salinan data, yang sayangnya umum pada sistem konsumen; mereka adalah kelemahan dalam konfigurasi yang berlebihan atau di mana Anda hanya ingin mendapatkan sebanyak mungkin dari drive sebelum memburuk lebih jauh.
  3. Drive akan terus mencoba membaca sektor yang buruk sampai mencapai ambang batas waktu habis atau sampai aborsi ditandai oleh host. Karena bus SATA dapat diikat oleh penantian agar pembacaan selesai, OS tidak mungkin memberi sinyal abortemen tingkat penyimpanan, dan dalam kasus yang ekstrem, drive mungkin tidak merespons dengan baik untuk reset bus SATA. dalam situasi seperti itu.

Poin # 1 adalah salah satu nilai jual utama untuk SAS di server; SAS memiliki penanganan kesalahan yang jauh lebih baik daripada SATA. Poin # 2 adalah batasan firmware drive, dan # 3 menjadi masalah karena # 2.

Jadi yang terjadi adalah OS mengeluarkan perintah "read sector" ke disk, dan sektor-sektor tertentu entah bagaimana rusak. Dengan demikian, disk akan masuk ke mode coba lagi untuk mencoba mendapatkan data dari piring-piring, mencoba membaca lagi dan lagi sampai mendapatkan data yang cukup baik bahwa koreksi kesalahan disk sendiri ( FEC ) dapat memperbaiki kesalahan yang tersisa. Jika Anda beruntung, ini mungkin tidak pernah, tetapi drive akan terus mencoba untuk jangka waktu yang cukup lama sebelum memutuskan bahwa pembacaan ini tidak akan berhasil.

Karena sistem operasi sedang menunggu pembacaan, ini setidaknya akan memperlambat proses penyalinan menjadi merangkak, dan tergantung pada arsitektur OS yang tepat dapat menyebabkan OS menjadi tersentak-sentak atau bahkan membeku selama durasi. Disk, pada titik ini, sibuk dengan pembacaan asli dan tidak akan menanggapi perintah pembacaan lebih lanjut sampai yang sedang menjalankan berakhir (berhasil atau tidak berhasil), dan perangkat lunak lain umumnya tidak akan melakukan lebih baik daripada sistem operasi itu. sedang berjalan.

Oleh karena itu, apa pun yang memicu pembacaan di tempat lain ( idealnya , hanya pada drive yang rusak) harus menunggu dalam antrean hingga drive yang rusak berhasil membaca sektor tersebut, atau menentukan bahwa itu tidak dapat dibaca. Karena penanganan drive nonresponsive SATA yang kurang optimal, ini dapat berarti bahwa tidak hanya drive yang Anda salin akan mengalami I / O tertunda. Ini dapat dengan mudah menyebabkan perangkat lunak lain menjadi lambat atau tidak responsif juga, karena perangkat lunak itu menunggu penyelesaian I / O yang berbeda untuk diselesaikan, bahkan jika sistem operasi mampu mengatasinya.

Penting juga untuk dicatat di sini bahwa disk I / O dapat terjadi meskipun Anda tidak secara eksplisit mengakses file apa pun pada disk. Dua penyebab utama untuk ini adalah kode eksekusi load-on-demand, dan swap. Karena swap kadang-kadang digunakan bahkan ketika sistem tidak berada di bawah tekanan memori, dan kode yang dapat dieksekusi load-on-demand adalah umum pada sistem modern dan dengan format file yang dapat dieksekusi modern, aktivitas pembacaan disk yang tidak diinginkan selama penggunaan normal adalah kemungkinan yang sangat nyata.

Seperti yang ditunjukkan dalam komentar terhadap pertanyaan oleh Matteo Italia , salah satu strategi mitigatif adalah menggunakan interkoneksi penyimpanan yang berbeda, yang merupakan cara rumit untuk mengatakan "memasukkan disk ke dalam selungkup USB". Dengan mengabstraksi melalui protokol penyimpanan massal USB , ini mengisolasi bagian SATA yang bermasalah dari seluruh sistem Anda, yang berarti bahwa secara teori , hanya I / O pada disk tertentu yang akan terpengaruh oleh masalah I / O pada disk tersebut.

Sebagai tambahan, ini adalah alasan mengapa SATA (khususnya, SATA tanpa drive-level ERC) sering tidak disarankan untuk RAID (terutama level RAID dengan redundansi, yang di antara yang standar adalah semua kecuali RAID 0 ); periode waktu tunggu yang lama dan penanganan kesalahan yang buruk dapat dengan mudah menyebabkan seluruh perangkat terlempar keluar dari array untuk bad sector tunggal, yang dapat ditangani dengan baik oleh pengontrol RAID jika ada redundansi dan pengontrol penyimpanan hanya tahu bahwa inilah masalahnya. SAS dirancang untuk array penyimpanan besar, dan dengan demikian dengan harapan bahwa akan ada masalah pada berbagai drive sesekali, yang menyebabkannya dirancang untuk menangani kasus drive bermasalah tunggal atau permintaan I / O dengan anggun.bahkan jika drive tidak. Disk bermasalah tidak sangat umum dalam sistem konsumen hanya karena mereka cenderung tidak memiliki banyak disk yang diinstal, dan yang diinstal hampir tidak pernah memiliki redundansi; karena SATA bertujuan untuk menggantikan PATA / IDE bukan SCSI (yang disebut SAS niche), kemungkinan fitur dan permintaan penanganan kesalahan (atau jaminan) dianggap memadai untuk kasus penggunaan yang dimaksudkan.

sebuah CVn
sumber
19
Terima kasih telah mengirim jawaban masuk akal yang menjelaskan apa yang terjadi. Ini adalah jenis pertanyaan di mana saya biasanya melihat jawaban yang tidak jelas seperti "karena sistem sedang menunggu drive" atau "karena dirancang seperti itu".
Mehrdad
4
@kasperd: Cukup banyak. Meskipun bagian dari itu adalah "kesalahan" Windows juga, karena itu dapat terjadi dengan mudah dengan beberapa pengontrol. IMO jawaban ini agak sengaja dibuat kabur , mengingat pengendali SAS perusahaan juga tidak kebal terhadap masalah ini. Itu benar-benar hanya bermuara pada permintaan I / O pemblokiran tertentu. Beberapa operasi hard drive memerlukan operasi X harus dijamin akan selesai sebelum operasi Y, dan jika X tidak pernah selesai, Y tidak pernah dapat memulai - dan apa pun setelah Y menjadi macet juga, tidak peduli apakah drive, controller, driver, atau OS berada di kesalahan.
qasdfdsaq
2
@JustAMartin Sebenarnya, hampir semuanya sudah async - perangkat apa pun yang mendukung DMA akhir-akhir ini penuh dengan asinkron; kernel hanya menjadwalkan permintaan dan menangani interupsi yang menandakan permintaan dilakukan. Masalahnya adalah bahwa kadang-kadang Anda harus menunggu operasi selesai - dan dalam prosesnya, mereka dapat memblokir sesuatu yang penting. Seperti yang dicatat oleh user20574, memori virtual adalah salah satunya, tetapi ada banyak hal yang memerlukan jaminan. Beberapa bagian dari kernel tidak sinkron, dan tentu saja, beberapa driver / perangkat hanya menghisap.
Luaan
2
@ MichaelKjörling "Karena sistem operasi menunggu pembacaan, setidaknya ini akan memperlambat proses penyalinan menjadi merangkak, dan tergantung pada arsitektur OS yang tepat dapat menyebabkan OS menjadi tersentak-sentak atau bahkan membeku selama durasi." - Mengapa OS menjadi tersentak dalam hal membaca dari drive sekunder (bukan sistem)? Masalahnya tidak bisa seluruhnya karena perilaku penanganan kesalahan dari pengontrol SATA. Saya pikir jawaban ini dapat mengambil manfaat dari informasi tentang bagaimana Windows menangani kesalahan dalam subsistem disk-nya.
Jordan Rieger
1
@ MichaelKjörling Cukup adil. Jawabannya memiliki banyak info bagus, tapi saya pikir itu tidak cukup menjelaskan skenario spesifik OP. Untuk melakukannya dari sudut yang berbeda, dapatkah Anda mengutip referensi apa pun untuk mendukung poin # 1: "Dengan SATA, jika drive berhenti merespons, ini dapat mengikat seluruh sistem penyimpanan, bukan hanya satu drive yang mengalami masalah Ini tentu berpotensi mengikat seluruh pengontrol. " ? Ini sepertinya desain yang mengerikan. Bukankah subsistem disk OS lebih mungkin menjadi biang keladinya? Yaitu pengendali tidak sinkron, tetapi driver OS kadang-kadang blok tidak perlu.
Jordan Rieger
3

Seperti yang dinyatakan di atas, masalah dengan sistem membeku karena hard drive yang buruk terutama disebabkan oleh upaya panjang oleh drive untuk memulihkan data yang tidak dapat dibaca dari sektor buruk. Salah satu nilai jual drive perusahaan adalah batas waktu baca yang sangat singkat untuk sektor yang gagal. Menggunakan drive perusahaan dapat mengurangi masalah Anda sampai tingkat tertentu, tetapi tidak akan menyelesaikannya.

Jawaban terbaik, bergerak maju, adalah menjaga cadangan yang tepat sehingga pemulihan tidak diperlukan. Mengubah perangkat lunak pemulihan tidak akan membuat perbedaan karena ini adalah masalah batas waktu firmware.

John Pace II
sumber
2

Mengapa hard drive yang rusak membekukan seluruh sistem?

Mereka tidak harus (secara umum). Ini benar-benar tergantung pada sistem file tertentu bagaimana kegagalan disk ditangani.

Pertimbangkan ZFS, yang dirancang dari bawah ke atas untuk menangani beberapa toleransi kesalahan. Berikut adalah video demo (dan satu dengan lebih banyak penjelasan ) di mana mereka menempatkan menjalankan drive pada landasan, mengambil ayunan dengan palu godam dan bor drive lain. Semua sementara ZFS terus berjalan.

Jens
sumber
2
Sebenarnya, ada kegagalan disk yang tidak bisa diatasi dengan ZFS. Misalnya, pembacaan sangat lama sebelum permintaan I / O habis, dalam pengaturan redundan atau non-redundan. (Anda dapat dengan mudah mengatur ZFS sedemikian rupa sehingga tidak memiliki redundansi.) Hal ini dapat dengan mudah menyebabkan drive terlempar keluar dari array di ZFS, yang jika ini menjatuhkan Anda di bawah ambang redundansi dapat menyebabkan seluruh array menjadi menjadi tidak tersedia. Jika diatur dengan failmode = tunggu, ini dapat menampilkan hasil yang serupa. Kegagalan seluruh disk sepenuhnya habis adalah kasus yang mudah untuk setiap subsistem penyimpanan; itu marginal drive yang menimbulkan masalah.
CVn
Dan sebelum Anda berpikir sebaliknya, saya sebenarnya menjalankan ZFS (hampir secara eksklusif) sendiri. Ini adalah sistem file yang hebat, dan manajer volume yang hebat, jika Anda berhati-hati dan tahu apa yang Anda lakukan. Namun, ini dirancang untuk sistem kelas perusahaan (workstation dan server kelas atas), dengan administrator dibayar untuk mengetahui apa yang mereka lakukan. Ini tidak dirancang untuk menangani dengan baik beberapa mode kegagalan yang terlihat pada perangkat keras komoditas, termasuk masalah RAM dan drive yang membutuhkan waktu terlalu lama untuk kembali dari permintaan I / O, dan itu tidak dirancang untuk kemudahan penggunaan untuk pengguna rumahan atau dalam kasus penggunaan pengguna rumahan.
CVn
Kecuali dalam video, ZFS tidak terus berjalan. Itu mulai berjalan lagi setelah melepaskan drive.
Christoffer Hammarström
-2

Saya pikir masalah yang Anda temui adalah bagian tingkat rendah dari OS mencoba berkali-kali untuk membaca blok buruk sebelum menyerah. Rutin ini diimplementasikan pada level rendah jika diperlukan selama booting atau operasi mandiri lainnya, dan karenanya sulit untuk membuatnya kembali masuk. Sistem operasi akan halaman terus menerus selama operasi normal dan sulit untuk memberikan prioritas pada permintaan yang bersaing karena sistem tingkat rendah tidak akan tahu prioritas proses yang memiliki permintaan paging.

jrrk
sumber
6
'Sistem tingkat rendah' memang mengetahui prioritas suatu proses yang meminta halaman; informasi tersebut disimpan dalam tabel halaman , meskipun implementasinya tergantung pada sistem tentang bagaimana prioritas ditangani. Ini bukan jawaban yang benar untuk pertanyaan ini - ini adalah masalah perangkat keras, bukan masalah OS.
Chris Cirefice
1
Saya pikir jawaban yang benar untuk pertanyaan itu adalah menolak untuk menggunakan drive yang rusak. Namun ini tidak akan memuaskan pengguna yang dimengerti ingin memulihkan data sebanyak mungkin.
jrrk