Hard drive membaca kesalahan yang ... berhenti?


10

Kisah saya dimulai dengan cukup sederhana. Saya memiliki server tugas ringan, menjalankan Arch Linux, yang menyimpan sebagian besar datanya pada RAID-1 yang terdiri dari dua drive SATA. Itu bekerja tanpa masalah selama sekitar 4 bulan. Lalu, tiba-tiba saya mulai mendapatkan kesalahan baca di salah satu drive. Selalu, pesannya sangat mirip:

Apr 18 00:20:15 hope kernel: [307085.582035] ata5.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Apr 18 00:20:15 hope kernel: [307085.582040] ata5.01: failed command: READ DMA EXT
Apr 18 00:20:15 hope kernel: [307085.582048] ata5.01: cmd 25/00:08:08:6a:34/00:00:27:00:00/f0 tag 0 dma 4096 in
Apr 18 00:20:15 hope kernel: [307085.582050]          res 51/40:00:0c:6a:34/40:00:27:00:00/f0 Emask 0x9 (media error)
Apr 18 00:20:15 hope kernel: [307085.582053] ata5.01: status: { DRDY ERR }
Apr 18 00:20:15 hope kernel: [307085.582056] ata5.01: error: { UNC }
Apr 18 00:20:15 hope kernel: [307085.621301] ata5.00: configured for UDMA/133
Apr 18 00:20:15 hope kernel: [307085.640972] ata5.01: configured for UDMA/133
Apr 18 00:20:15 hope kernel: [307085.640986] sd 4:0:1:0: [sdd] Unhandled sense code
Apr 18 00:20:15 hope kernel: [307085.640989] sd 4:0:1:0: [sdd]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 18 00:20:15 hope kernel: [307085.640993] sd 4:0:1:0: [sdd]  Sense Key : Medium Error [current] [descriptor]
Apr 18 00:20:15 hope kernel: [307085.640998] Descriptor sense data with sense descriptors (in hex):
Apr 18 00:20:15 hope kernel: [307085.641001]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
Apr 18 00:20:15 hope kernel: [307085.641010]         27 34 6a 0c 
Apr 18 00:20:15 hope kernel: [307085.641020] sd 4:0:1:0: [sdd]  Add. Sense: Unrecovered read error - auto reallocate failed
Apr 18 00:20:15 hope kernel: [307085.641023] sd 4:0:1:0: [sdd] CDB: Read(10): 28 00 27 34 6a 08 00 00 08 00
Apr 18 00:20:15 hope kernel: [307085.641027] end_request: I/O error, dev sdd, sector 657746444
Apr 18 00:20:15 hope kernel: [307085.641035] ata5: EH complete
Apr 18 00:20:15 hope kernel: [307085.641672] md/raid1:md16: read error corrected (8 sectors at 657744392 on sdd1)
Apr 18 00:20:17 hope kernel: [307087.505082] md/raid1:md16: redirecting sector 657742336 to other mirror: sdd1

Setiap kesalahan mengeluhkan nomor sektor yang berbeda, dan disertai dengan penundaan beberapa detik untuk pengguna (saya) mengakses disk.

Saya memeriksa output smartctl, dan melihat output berikut (bagian yang tidak relevan terpotong):

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   193   193   051    Pre-fail  Always       -       1606
  5 Reallocated_Sector_Ct   0x0033   194   194   140    Pre-fail  Always       -       0
196 Reallocated_Event_Count 0x0032   162   162   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       51

Melihat kembali log, saya menemukan bahwa kesalahan sebenarnya telah terjadi selama beberapa hari, sebagian besar selama pencadangan, tetapi juga sering selama penggunaan yang sangat ringan (artinya setiap 5 kali saya mencoba menyimpan file teks). Saya menyimpulkan bahwa disk saya sedang sekarat, bahwa RAID-1 menanganinya dengan tepat, dan sudah waktunya untuk memesan disk pengganti. Saya memesan disk baru.

Sangat mengejutkan saya, sehari kemudian, kesalahannya ... berhenti. Saya tidak melakukan apa pun untuk memperbaikinya. Saya belum reboot, tidak mengambil drive offline, tidak ada. Tapi kesalahannya berhenti begitu saja.

Pada saat itu, penasaran untuk melihat apakah bad sector hanya berada di bagian disk yang tidak digunakan sekarang, saya mengeluarkan disk dari RAID, memasukkannya kembali ke dalam RAID, dan membiarkannya menyelesaikan resync lengkap berikutnya. Sinkronisasi ulang selesai tanpa kesalahan, 9 jam kemudian (disk 2TB butuh waktu agak lama).

Juga, output smartctl telah berubah sedikit, sebagai berikut:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   193   193   051    Pre-fail  Always       -       1606
  5 Reallocated_Sector_Ct   0x0033   194   194   140    Pre-fail  Always       -       43
196 Reallocated_Event_Count 0x0032   162   162   000    Old_age   Always       -       38
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0

Jadi, bagian dari ini yang membuat saya keluar tentu saja adalah, "Sejak kapan disk buruk memperbaiki diri mereka sendiri?"

Saya kira itu mungkin bahwa area yang sangat kecil dari drive secara spontan menjadi buruk, dan bahwa drive hanya membutuhkan 3 hari (!) Sebelum kode realokasi sektornya menendang dan memetakan beberapa sektor cadangan di atas area yang buruk dari disk ... Tetapi saya tidak dapat mengatakan bahwa saya pernah melihat itu terjadi.

Adakah orang lain yang melihat perilaku seperti ini? Jika demikian, apa pengalaman Anda dengan drive sesudahnya? Apakah itu terjadi lagi? Apakah disk akhirnya gagal sepenuhnya? Atau apakah itu hanya kesalahan yang tidak dapat dijelaskan yang tetap tidak dapat dijelaskan?

Dalam kasus saya, saya sudah memiliki drive pengganti (diperoleh dalam garansi), jadi saya mungkin akan mengganti drive saja. Tapi saya ingin tahu apakah saya salah mendiagnosis hal ini. Jika ini membantu, saya memiliki keluaran 'smartctl -a' yang lengkap sejak masalah terjadi. Ini agak panjang, jadi saya tidak mempostingnya di sini.


Apa yang dimaksud dengan make & model drive?
Antonius Bloch

Ini adalah drive Western Digital Caviar Black 2TB, model WD2001FAAS. Saya tahu, bukan disk kelas server, tetapi juga bukan server tingkat produksi pusat data.
Rick Koshi

Jawaban:


9

Jika satu wilayah fisik tertentu dari permukaan drive memburuk, maka hingga sektor-sektor tersebut dapat dipetakan dengan sukses, Anda akan mendapatkan kesalahan baca yang tidak dapat dipulihkan saat Anda mencoba membaca data apa pun yang ditulis pada area tersebut. Drive tahu bahwa sektor-sektor buruk (setelah kegagalan mengakses sektor-sektor) tetapi tidak dapat memetakan kembali sektor-sektor karena mereka sudah menyimpan data. Jika Anda memformat drive atau menimpa sektor "buruk", maka drive tersebut akan memiliki peluang untuk memetakan sektor buruk.

Setelah bad sector dipetakan, dan selama lebih banyak permukaan drive tidak gagal, Anda dalam kondisi yang baik.

Saya tidak cukup tahu tentang model kegagalan drive dari drive saat ini untuk mengetahui apakah ada banyak korelasi antara satu bagian permukaan media yang memburuk dan masalah menyebar atau terjadi lagi. Jika tidak ada korelasi, maka setelah bad sector dipetakan, Anda dalam kondisi yang baik. Jika ada adalah korelasi, maka ini adalah awal dari akhir untuk drive.


4

Sebagian besar drive modern akan "vektor keluar" blok yang sudah rusak. Drive memiliki kumpulan blok cadangan dan firmware menggunakan ini untuk mengganti blok yang diketahui drive menjadi buruk. Drive tidak dapat melakukan pemetaan ulang ini ketika gagal MEMBACA blok karena tidak dapat menyediakan data yang benar. Itu hanya mengembalikan "kesalahan baca". Itu MARK blok sebagai buruk, jadi jika blok pernah membaca dengan benar maka blok itu vektor keluar dan data yang benar ditulis ke blok pengganti. Jika OS pernah MENULIS ke blok yang dalam keadaan "vector out pending" maka blok tersebut di-vektor dan data ditulis ke blok pengganti.

Linux raid software akan, pada mendapatkan kesalahan baca dari perangkat, mendapatkan data yang benar dari elemen lain dalam array dan kemudian mencoba MENULIS blok buruk lagi. JADI, jika penulisan bekerja OK maka data aman, jika tidak, drive hanya melakukan di atas, vektor blok dan kemudian melakukan menulis. JADI, drive itu, dengan bantuan sistem raid, baru saja diperbaiki sendiri!

Dengan asumsi kejadian seperti itu cukup langka, mungkin aman untuk melanjutkan. Jika terlalu banyak blok pengganti yang digunakan maka drive mungkin memiliki masalah. Ada batasan berapa banyak blok pengganti yang dapat di-vektor-kan ke blok cadangan dan itu adalah fungsi drive.


3

Ya, saya telah melihat ini juga, dan dalam keadaan yang sangat mirip. Dalam kasus saya, itu adalah drive "Green" 1RB "Digital-grade" Consumer-grade (WD10EARS) yang menarik perhatian saya. Nilai Current_Pending_Sectormentah SMART berubah dari nol menjadi 6, dan kemudian ke 8, mendorong daemon pemantauan SMART untuk mengirimi saya beberapa email yang tidak menyenangkan.

Saya mdadm --failed dan --removed drive dari array dan menjalankan pass non-destruktif badblocksatasnya, dan ya, ternyata ada lebih dari 2 lusin blok buruk. Ketika drive pengganti tiba sekitar sehari kemudian, saya memperbaiki array, dan hidup terus berjalan.

Tidak lama kemudian, karena bosan, saya memutar badblockskembali drive yang "gagal" untuk melihat apakah sudah memburuk. Sebaliknya, drive itu benar-benar "diperbaiki" sendiri: nol blok buruk! Sambil menggelengkan kepala, saya menyeka dan menyisihkannya untuk didaur ulang atau disumbangkan.

Pelajaran: Jangan gunakan drive tingkat konsumen di server, kecuali jika Anda bersedia dan mampu memasang dengan segala macam keanehan dan tidak dapat diandalkan. Akibat wajar: Jangan murah pada komponen server, karena pada akhirnya Anda akan membayarnya, dalam waktu ekstra dan kejengkelan.


Jika blok buruk yang ditemukan berhasil dipetakan, dan tidak ada sektor tambahan yang rusak, maka hasil Anda adalah yang Anda harapkan. Paragraf terakhir Anda masih merupakan jawaban yang tepat.
Eddie

0

Ini adalah praktik umum di lingkungan server untuk membuang drive yang pernah menunjukkan kesalahan seperti itu, diperbaiki atau tidak. Kesalahan keras sektor dapat menjadi tanda kerusakan permukaan fisik pada medium - dan jika Anda menggores permukaan, Anda biasanya memindahkan material ke sisi goresan dan mendapatkan duri yang lebih tinggi daripada bidang permukaan seperti itu - atau debu abrasif (kaca! ). Keduanya cenderung agak merusak sistem mekanik yang bergantung pada bantalan udara yang sangat tipis antara dua permukaan yang diasumsikan sangat halus ... itulah sebabnya kesalahan sedang setelah mereka mulai mencapai hitungan tertentu cenderung berkembang biak agak lebih cepat.

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.