เคอร์เนล: เจอร์นัลยอมรับข้อผิดพลาด I / O

9

ฉันมีปัญหากับเซิร์ฟเวอร์ Dell 1950 ฉันกำลังติดตั้ง RHEL 4.6 พร้อมกับ Oracle และซอฟต์แวร์อื่น ๆ ที่นี่

ฉันสุ่มรับข้อความแสดงข้อผิดพลาดว่า "kernel: journal commit I / O error" ในเซสชั่น ssh ของฉันและบนจอภาพฉันได้ติดกับเซิร์ฟเวอร์ฉันเห็นข้อผิดพลาดในการเลื่อนโดยระบุว่า "ข้อผิดพลาด EXT3-fs (อุปกรณ์ sda5) ใน start_transaction: วารสารยกเลิกแล้ว "

มันเกิดขึ้นหลายครั้ง แต่ไม่เคยถึงจุดเดียวกันในระหว่างการติดตั้ง ที่จริงแล้วครั้งสุดท้ายที่ระบบเริ่มทำงานและฉันพยายามนำเข้าฐานข้อมูลเข้าสู่ oracle

สิ่งนี้เกิดขึ้นกับฮาร์ดไดรฟ์หลายตัวดังนั้นฉันค่อนข้างแน่ใจว่าไม่ใช่ปัญหา นี่ทำให้ฉันคิดว่าตัวควบคุมการจู่โจมแย่

พวกคุณคิดอย่างไร

** อัพเดท **

ค่อนข้างแน่ใจว่ามันเป็นฮาร์ดไดรฟ์ที่ไม่ดี ฉันโยนไดรฟ์อื่นในเซิร์ฟเวอร์และมันใช้งานมาได้ประมาณ 48 ชั่วโมงโดยไม่มีปัญหา

linux raid ext3

— jasondewitt
แหล่งที่มา

9

ฉันเคยเห็นข้อผิดพลาดเหล่านั้นมาก่อน แต่ไม่พบในระหว่างกระบวนการติดตั้ง

หมายความว่าไดรฟ์มีข้อผิดพลาดมากพอที่ระบบปฏิบัติการนำไปสู่โหมดอ่านอย่างเดียว หากคุณสามารถค้นหาบันทึกแบบเต็มอาจเป็นไปได้ว่ามีข้อผิดพลาดของ I / O บางอย่างที่ลองใหม่และทำงานก่อนข้อผิดพลาดความล้มเหลวแบบเต็มเมื่อคุณเห็น บางสิ่งบางอย่างที่มีการกล่าวถึงบล็อกจริง

มันเป็นข้อผิดพลาดของระบบจัดเก็บข้อมูล แน่นอนว่าเป็นการ์ด RAID, ไดรฟ์ในอาร์เรย์ RAID, สายเคเบิลจากการ์ดไปยังไดรฟ์, แบ็คเพลนที่ไดรฟ์เชื่อมต่อ, สล็อตที่เสียบการ์ดจู่โจมเข้ากับแหล่งจ่ายไฟสำหรับฮาร์ดไดรฟ์หรืออย่างอื่นใน ระหว่าง CPU และหน่วยเก็บข้อมูลจริง

— Freiheit
แหล่งที่มา

2

ความเป็นไปได้สามประการที่อยู่ในใจ:

มีปัญหาหน่วยความจำ (พวกเขามักจะทำให้เกิดปัญหา "สุ่ม") หากคุณมีหน่วยความจำ ECC อยู่ที่นั่นแน่นอนว่ามีโอกาสน้อยกว่า
มีปัญหาบางอย่างกับรถบัส ฉันมีปัญหาเดียวกันกับคอนโทรลเลอร์ APIC ที่ใช้งานไม่ได้บนเมนบอร์ด Tyan dual Opteron ไม่กี่ปีก่อน มีรายการบันทึกอื่น ๆ ที่บอกเป็นนัย แต่ส่วนใหญ่ของอาการคือความเสียหายแบบสุ่มในดิสก์ไดรฟ์ที่มี remounts แบบอ่านอย่างเดียวโดยอัตโนมัติ ในกรณีของฉันฉันรู้ว่ามันไม่เกี่ยวข้องกับดิสก์เพราะมันเป็นกล่อง FC RAID ภายนอกและมันก็ใช้ได้
ตัวควบคุม RAID นั้นเป็นสองชั้น

นี่คือลำดับฉันจะพิจารณาปัญหา

— Alexandre Carmel-Veilleux
แหล่งที่มา

อาจไม่ใช่ปัญหาหน่วยความจำ สิ่งเหล่านั้นมีแนวโน้มที่จะก่อให้เกิด segfaults และข้อผิดพลาดแบบสุ่มมากขึ้นไม่ จำกัด เฉพาะที่จัดเก็บ

— freiheit

จริง แต่ในสถานการณ์การติดตั้งหรือการบูตก่อนหน้าการใช้หน่วยความจำจำนวนมากคือบัฟเฟอร์แคชดังนั้นปัญหามักจะปรากฏที่นั่นก่อน เมื่อเครื่องทำงานโหลดมาระยะหนึ่งแล้วผู้ใช้จะควบคุม I / O หน่วยความจำและความแพร่หลายของ segfault PE1950 ควรมีโปรเซสเซอร์ Xeon และ ECC ram ดังนั้น RAM ควรสามารถตรวจจับได้และรายงานไปยัง Linux

— Alexandre Carmel-Veilleux

2

อาจเป็นคอนโทรลเลอร์ RAID ที่ไม่ดีอย่างที่คุณพูด (ลองใช้อะไหล่ถ้าคุณมี) มันอาจเป็นไดรเวอร์สำหรับคอนโทรลเลอร์ (ตรวจสอบไดรเวอร์อื่น ๆ ถ้ามี) แม้ว่าประสิทธิภาพจะแย่ลงก็ดีที่มีจุดอ้างอิง .) อาจเป็นเคอร์เนล (มีโอกาสน้อยกว่าใน RHEL แต่ผ่านการทดสอบค่อนข้างดี) อาจเป็น RAM ที่ไม่ดีที่ทำแคชบล็อกได้

อย่างไรก็ตามปัญหาฮาร์ดแวร์เป็นสาเหตุที่เป็นไปได้มากที่สุดโดยดูจากพฤติกรรมข้อผิดพลาดแบบสุ่ม

— มิยะลิมเบีย
แหล่งที่มา

2

ตรวจสอบว่าดิสก์ไม่เต็มโดยเฉพาะรูตพาร์ติชัน ใช้ df เพื่อดูการใช้งานดิสก์ระบบไฟล์:

df -h

ค้นหาพาร์ติชันที่อยู่ใกล้หรือเท่ากับการใช้งาน 100%

— ปีเตอร์เอช
แหล่งที่มา

-5

ลอง:

ปิด -rF ทันที