Saya memiliki drive Ironwolf yang melaporkan status SMART tidak normal dengan jumlah sektor abnormal sebanyak 10, tetapi IronWolf Health Monitor mengatakan bahwa drive tersebut sehat. Saya sedang melakukan pemindaian untuk bad block, tetapi apakah ada hal lain yang perlu saya lakukan? Drive tersebut hanya memiliki waktu operasi 492 hari.
Bisakah Anda menguji disk secara eksternal? Jika memang ada kesalahan, seharusnya masih ada garansi.
Pemindaian blok buruk masih berjalan, tetapi telah melaporkan URE. IHM masih mengatakan drive sehat.
Saya mulai bertanya-tanya apakah IHM benar-benar berarti sesuatu, atau apakah QNAP TERLALU sensitif… tapi URE memberi tahu saya bahwa monitor kesehatan itu tidak berguna.
Setelah pemindaian blok buruk selesai, apa ambang batas untuk penggantian garansi Seagate? Apakah harus benar-benar gagal total? Atau bisakah saya memberi tahu mereka “X sektor telah gagal, kirimkan pengganti dan saya akan melakukan zeroing pada drive yang bermasalah lalu mengirimkannya kembali kepada Anda.”
16 blok rusak terdeteksi. Telah menjalankan tes SMART penuh, mendapat hasil “Fatal atau error tidak diketahui”.
IHM masih mengatakan drive baik-baik saja. Apakah Seagate akan menggantinya di bawah garansi jika IHM tidak melaporkan masalah? Sepertinya saya akan menelepon dukungan pada hari Senin dan bertanya.
Seagate akan meminta Anda untuk mengujinya dengan alat mereka sendiri.
Ketika SMART mendeteksi masalah, meskipun IHM menunjukkan bahwa drive masih berfungsi, hal ini tidak menutup kemungkinan adanya potensi risiko tersembunyi pada hard drive.
Berdasarkan prinsip bahwa data Anda adalah yang utama, kami tetap menyarankan agar Anda mencadangkan data Anda dan mengganti hard drive. Tindakan ini akan membantu mencegah kehilangan data yang tidak terduga.
Seagate telah mengeluarkan RMA untuk drive tersebut. Saya akan melepaskannya, menghubungkannya ke server melalui dock, dan menggunakan perintah shred untuk menghapus data pada perangkat sebelum mengirimkannya kembali.
PERTANYAAN: Ini adalah array RAID6. Apakah masih bisa digunakan dalam keadaan DEGRADED (terdegradasi)? Atau apakah storage pool akan berubah menjadi mode hanya-baca (read-only)?
Jadi, saya melepas drive, mencabutnya, dan mengeluarkannya dari tray lalu memasangnya ke dock USB 3.0 SATA yang terhubung ke salah satu server Linux saya. Saya menggunakan perintah shred untuk menghapus data di drive sebelum mengembalikannya ke Seagate. Setelah itu saya menjalankan smartctl, dan SMART masih melaporkan adanya kerusakan. Di bagian catatan kecil pada dokumen garansi Seagate tertulis bahwa klaim akan ditolak jika tidak ditemukan masalah. Jadi saya mengunduh dan menginstal SeaTools dan melakukan tes panjang pada drive tersebut. Hasilnya lolos. Jadi kemungkinan besar mereka hanya akan mengirimkannya kembali kepada saya. Saya pasang kembali dan masukkan ke NAS, dan sekarang sedang melakukan rebuilding. Statusnya tertulis Healthy.
Dari sudut pandang teknologi: drive modern memiliki sektor cadangan. Jika sebuah sektor dinyatakan rusak, firmware akan memetakan ulang ke sektor cadangan. Perintah shred menulis 3 kali data acak ke drive… Saya membatalkannya sekitar sepertiga jalan pada putaran ketiga. Tidak ada error yang dilaporkan selama proses shred. Sangat mungkin penulisan tersebut menyebabkan blok rusak dipindahkan di drive, dan sekarang semuanya baik-baik saja.
Namun, saya tetap tidak sepenuhnya percaya pada drive ini. Saya BERENCANA untuk upgrade drive tahun depan. DRIVE INI akan menjadi yang PERTAMA diganti dengan WD RED yang lebih besar.
SMART seharusnya menunjukkan bahwa ada sektor yang dipindahkan (karena ada nilainya)
Anehnya, statistik ITU adalah 0:
retired_block_count: Value: 100, Worst: 100, Threshold: 10, Raw value: 0
Dalam statistik SMART LENGKAP yang saya dapatkan dari penggunaan smartctl:
Device Statistics (GP Log 0x04)
Page Offset Size Value Flags Description
0x03 0x020 4 0 — Jumlah Sektor Logis yang Direalokasi
0x03 0x028 4 20 — Upaya Pemulihan Baca
0x03 0x030 4 0 — Jumlah Kegagalan Start Mekanis
0x03 0x038 4 0 — Jumlah Sektor Kandidat Realokasi Logis
0x03 0x040 4 3 — Jumlah Event Unload Prioritas Tinggi
0x04 ===== = = === == Statistik Error Umum (rev 1) ==
0x04 0x008 4 18 — Jumlah Error Tidak Terkoreksi yang Dilaporkan
0x04 0x010 4 0 — Reset Antara Penerimaan dan Penyelesaian Perintah
0x04 0x018 4 0 -D- Status Elemen Fisik Berubah
Dalam log FARM:
FARM Log Page 3: Statistik Error
Error Baca yang Tidak Dapat Dipulihkan: 0
Error Tulis yang Tidak Dapat Dipulihkan: 0
Jumlah Sektor yang Direalokasi: 0
Jumlah Upaya Pemulihan Baca: 20
Jumlah Kegagalan Start Mekanis: 0
Jumlah Sektor Kandidat Realokasi: 0
Jumlah Event ASR: 24
Error tidak terkoreksi: 0
Error Baca Tidak Dapat Dipulihkan Seumur Hidup Akumulatif karena ERC: 0
…
Error Tidak Dapat Dipulihkan Seumur Hidup oleh head 7:
Error Baca Tidak Dapat Dipulihkan Seumur Hidup Berulang: 18
Error Baca Tidak Dapat Dipulihkan Seumur Hidup Unik: 0
FARM Log Page 5: Statistik Keandalan
Error Rate (SMART Attribute 1 Raw): 0x000000000bf750ae
Error Rate (SMART Attribute 1 Normalized): 83
Error Rate (SMART Attribute 1 Worst): 64
Seek Error Rate (SMART Attr 7 Raw): 0x0000000022dc4e9e
Seek Error Rate (SMART Attr 7 Normalized): 88
Seek Error Rate (SMART Attr 7 Worst): 60
Event Unload Prioritas Tinggi: 3
Helium Pressure Threshold Tripped: 0
LBAs Dikoreksi oleh Parity Sector: 1
Berdasarkan ini, sepertinya drive mengalami gangguan sementara, QNAP panik, dan sekarang semuanya tampak baik-baik saja. Tentu saja, 18 error tersebut tercatat.
Error ke-18 terjadi pada masa pakai disk: 11814 jam (492 hari + 6 jam)
Error: UNC di LBA = 0x0fffffff = 268435455
Error ke-17:
Error: WP di LBA = 0x0fffffff = 268435455
Dan tentu saja, riwayat self test menunjukkan:
#3 Extended offline Selesai: kegagalan baca 90% 11830 1580896880
Pengujian selanjutnya mengatakan semuanya baik-baik saja. Setelah rebuild selesai, saya berniat untuk memulai tes SMART penuh lagi, lalu scan bad block. Ini benar-benar aneh, dan itu datang dari seseorang yang sudah pernah menangani gangguan sementara sebelumnya. Ini tidak benar-benar meningkatkan kepercayaan saya pada Seagate. Saya rasa jika ini terjadi lagi, saya akan memulai RAID scrub (bagi yang lebih familiar dengan mdadm, “echo resync > /sys/block/md1/md/sync_action” yang pada dasarnya akan melakukan writeback dan validasi parity. Pada RAID 5, error blok bisa merusak data Anda secara fatal, tapi dengan RAID 6, bit parity ekstra biasanya bisa menyelesaikannya. Mengeluarkan drive, menghapusnya, lalu memasukkannya kembali dan membiarkan sistem membangunnya ulang juga bisa, tapi memakan waktu lebih lama. Sisi positifnya: drive yang sudah dihapus TIDAK BISA mengacaukan perhitungan parity.
Anda juga dapat melakukan RAID scrub melalui GUI
Nilai FARM tersebut baru-baru ini menjadi berita, sebagai satu-satunya indikator penipuan drive yang salah label secara besar-besaran pada drive Seagate
Ini mungkin dapat membantu Anda: Why does my NAS show an 'Abnormal' S.M.A.R.T. status but IHM reports the drive as 'Healthy'? | QNAP