Dmesg penuh dengan kesalahan I / O, pintar ok, empat disk terpengaruh

Saya sedang mengerjakan server jarak jauh (Dell Poweredge) yang merupakan instalasi baru. Ini memiliki empat drive (2TB) dan 2 SSD (250 GB). Satu SSD berisi OS (RHEL7) dan empat disk mekanis pada akhirnya akan berisi database oracle.

Mencoba membuat perangkat lunak RAID array menyebabkan disk terus-menerus ditandai sebagai salah. Memeriksa dmesg menghasilkan banyak kesalahan berikut,

[127491.711407] blk_update_request: I/O error, dev sde, sector 3907026080
[127491.719699] sd 0:0:4:0: [sde] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[127491.719717] sd 0:0:4:0: [sde] Sense Key : Aborted Command [current]
[127491.719726] sd 0:0:4:0: [sde] Add. Sense: Logical block guard check failed
[127491.719734] sd 0:0:4:0: [sde] CDB: Read(32)
[127491.719742] sd 0:0:4:0: [sde] CDB[00]: 7f 00 00 00 00 00 00 18 00 09 20 00 00 00 00 00
[127491.719750] sd 0:0:4:0: [sde] CDB[10]: e8 e0 7c a0 e8 e0 7c a0 00 00 00 00 00 00 00 08
[127491.719757] blk_update_request: I/O error, dev sde, sector 3907026080
[127491.719764] Buffer I/O error on dev sde, logical block 488378260, async page read
[127497.440222] sd 0:0:5:0: [sdf] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[127497.440240] sd 0:0:5:0: [sdf] Sense Key : Aborted Command [current]
[127497.440249] sd 0:0:5:0: [sdf] Add. Sense: Logical block guard check failed
[127497.440258] sd 0:0:5:0: [sdf] CDB: Read(32)
[127497.440266] sd 0:0:5:0: [sdf] CDB[00]: 7f 00 00 00 00 00 00 18 00 09 20 00 00 00 00 00
[127497.440273] sd 0:0:5:0: [sdf] CDB[10]: 00 01 a0 00 00 01 a0 00 00 00 00 00 00 00 00 08
[127497.440280] blk_update_request: I/O error, dev sdf, sector 106496
[127497.901432] sd 0:0:5:0: [sdf] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[127497.901449] sd 0:0:5:0: [sdf] Sense Key : Aborted Command [current]
[127497.901458] sd 0:0:5:0: [sdf] Add. Sense: Logical block guard check failed
[127497.901467] sd 0:0:5:0: [sdf] CDB: Read(32)
[127497.901475] sd 0:0:5:0: [sdf] CDB[00]: 7f 00 00 00 00 00 00 18 00 09 20 00 00 00 00 00
[127497.901482] sd 0:0:5:0: [sdf] CDB[10]: e8 e0 7c a0 e8 e0 7c a0 00 00 00 00 00 00 00 08
[127497.901489] blk_update_request: I/O error, dev sdf, sector 3907026080
[127497.911003] sd 0:0:5:0: [sdf] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[127497.911019] sd 0:0:5:0: [sdf] Sense Key : Aborted Command [current]
[127497.911029] sd 0:0:5:0: [sdf] Add. Sense: Logical block guard check failed
[127497.911037] sd 0:0:5:0: [sdf] CDB: Read(32)
[127497.911045] sd 0:0:5:0: [sdf] CDB[00]: 7f 00 00 00 00 00 00 18 00 09 20 00 00 00 00 00
[127497.911052] sd 0:0:5:0: [sdf] CDB[10]: e8 e0 7c a0 e8 e0 7c a0 00 00 00 00 00 00 00 08
[127497.911059] blk_update_request: I/O error, dev sdf, sector 3907026080
[127497.911067] Buffer I/O error on dev sdf, logical block 488378260, async page read

Kesalahan ini terjadi untuk semua empat disk mekanis, (sdc / sdd / sde / sdf) SMARTctl melewati keempat disk, tes panjang dan pendek. Saat ini saya sedang menjalankan badblocks (tes mode tulis ~ 35 jam, mungkin 35 detik lagi).

Berikut ini adalah kesalahan yang saya duga / pertimbangkan pada penelitian

HDD Gagal - Sepertinya tidak mungkin 4 disk yang "diperbarui" adalah DOA, bukan?
Masalah Pengontrol Penyimpanan (kabel buruk?) - Sepertinya itu akan mempengaruhi SSD juga?
- Masalah kernel, Satu-satunya perubahan pada stok kernel adalah penambahan kmod-oracleasm. Saya benar-benar tidak melihat bagaimana ini akan menyebabkan kesalahan ini, ASM tidak diatur sama sekali.

Peristiwa penting lainnya adalah ketika mencoba untuk membidik disk (bagian dari pemecahan masalah awal), menggunakan perintah $ dd jika = / dev / nol dari = / dev / sdX menghasilkan kesalahan ini,

dd: writing to ‘/dev/sdc’: Input/output error
106497+0 records in
106496+0 records out
54525952 bytes (55 MB) copied, 1.70583 s, 32.0 MB/s
dd: writing to ‘/dev/sdd’: Input/output error
106497+0 records in
106496+0 records out
54525952 bytes (55 MB) copied, 1.70417 s, 32.0 MB/s
dd: writing to ‘/dev/sde’: Input/output error
106497+0 records in
106496+0 records out
54525952 bytes (55 MB) copied, 1.71813 s, 31.7 MB/s
dd: writing to ‘/dev/sdf’: Input/output error
106497+0 records in
106496+0 records out
54525952 bytes (55 MB) copied, 1.71157 s, 31.9 MB/s

Jika ada orang di sini yang bisa berbagi wawasan tentang apa yang menyebabkan ini, saya akan berterima kasih. Saya cenderung mengikuti Occam's silet di sini dan langsung ke HDD, satu-satunya keraguan berasal dari kemungkinan empat HDD gagal di luar kotak.

Saya akan pergi ke lokasi besok untuk pemeriksaan fisik & melaporkan penilaian saya tentang mesin ini kepada atasan. Jika ada sesuatu yang harus saya periksa secara fisik (di luar kabel / koneksi / catu daya) beri tahu saya.

Terima kasih.

— Scu11y
sumber

Ketika Anda mengatakan SMART "ok", apakah yang Anda maksudkan adalah kesehatan secara keseluruhan? Apakah ada penghitung mentah individu untuk sektor yang dialokasikan kembali atau yang tertunda bukan nol? Drive tidak langsung menyatakan gagal pada sektor buruk pertama, meskipun tidak dapat dibaca. Gunakan smartctl -x /dev/sdaatau apalah. Tapi itu sangat mencurigakan bahwa itu adalah LBA yang sama pada semua disk.

— Peter Cordes

ddTes Anda menunjukkan keempat disk semuanya gagal pada alamat LBA yang sama . Karena sangat mustahil bahwa empat disk semuanya gagal pada lokasi yang sama persis, saya sangat curiga itu karena masalah pengontrol atau pemasangan kabel.

— shodanshok
sumber

Sulit untuk mengatakannya tanpa pengujian lebih lanjut. Ngomong-ngomong, pikir pertama yang akan saya kontrol / ganti adalah kabel yang memasang controller ke backplane.

— shodanshok

Kabel data-rate tinggi, seperti yang 6/12 Gbs SATA / SAS, tidak hanya tentang kontinuitas listrik, tetapi terutama tentang kejelasan sinyal dan kebisingan yang rendah. Coba hapus konektor dan pasang kembali kabel secara fisik. Jika kesalahan berlanjut, coba ubah dan, akhirnya, coba pengontrol lain.

— shodanshok

Sama-LBA tampaknya tidak mungkin menjadi masalah pemasangan kabel. Kecuali jika data di sektor tersebut hanya merupakan urutan bit kasus terburuk untuk beberapa pengacakan (untuk mencegah berlama-lamanya mengalahkan self-clocking) atau ECC melalui tautan SATA / SAS. Saya tidak yakin pengodean apa yang digunakan tautan. Kontroler masuk akal; LBA yang sama pada masing-masing beberapa disk memerlukan semacam penjelasan faktor umum.

— Peter Cordes

@ djsmiley2k Sulit bahwa keempat ujungnya dddi-cache pada alamat RAM yang sama dan gagal. Selain itu, DRAM PERC dilindungi ECC dan, sementara ECC RAM juga gagal, ini relatif jarang terjadi. Yang mengatakan, controller dapat menjadi sumber masalah jadi, jika mengganti kabel tidak membantu, OP harus mencoba bertukar controller.

— shodanshok

Nah teman-teman saya, Anda benar. Kabel + pengontrol bertukar dan sekarang 600GB ke dalam proses zeroing dd dan sejauh ini tidak ada kesalahan. Sepertinya semuanya bekerja dengan benar sekarang. Sekali lagi terima kasih atas semua pengetahuan yang Anda bagikan. Saya selalu berterima kasih kepada komunitas ini atas keahlian dan kesediaan Anda untuk membagikannya. :)

— Scu11y