Linux, วิธีเปลี่ยนสถานะ HDD จาก ReadOnly หลังจากเกิดข้อผิดพลาดชั่วคราว?

ในเวลานี้ไม่มีคำตอบสำหรับปัญหานี้

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

ตัวอย่างจาก dmesg นี่คือการจำลองสำหรับ guest linux บน windows8 โดยใช้ VirtualBox เมื่อ defrag ใช้อิมเมจอุปกรณ์แขก:

[11903.002030] ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
[11903.003179] ata3.00: failed command: READ FPDMA QUEUED
[11903.003364] ata3.00: cmd 60/08:00:a8:77:57/00:00:00:00:00/40 tag 0 ncq 4096 in
[11903.003385]          res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[11903.004074] ata3.00: status: { DRDY }
[11903.004248] ata3: hard resetting link
[11903.325703] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[11903.327097] ata3.00: configured for UDMA/133
[11903.328025] ata3.00: device reported invalid CHS sector 0
[11903.329664] ata3: EH complete
[11941.000472] ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
[11941.000769] ata3.00: failed command: READ FPDMA QUEUED
[11941.000952] ata3.00: cmd 60/08:00:c8:77:57/00:00:00:00:00/40 tag 0 ncq 4096 in
[11941.000961]          res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[11941.001353] ata3.00: status: { DRDY }
[11941.001504] ata3: hard resetting link
[11941.320297] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[11941.321252] ata3.00: configured for UDMA/133
[11941.321379] ata3.00: device reported invalid CHS sector 0
[11941.321553] ata3: EH complete
[11980.001746] ata3.00: exception Emask 0x0 SAct 0x11fff SErr 0x0 action 0x6 frozen
[11980.002070] ata3.00: failed command: WRITE FPDMA QUEUED
[11980.002255] ata3.00: cmd 61/18:00:28:23:59/00:00:00:00:00/40 tag 0 ncq 12288 out
[11980.002265]          res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
-------------------
There are many other errors, like "lost write page", "Journal has aborted", "Buffer I/O error", "hard resetting link" and many others.

หลังจากนี้ให้นับใหม่:

mount / -o remount,rw
mount: cannot remount block device /dev/sda1 read-write, is write-protected

เนื่องจากอุปกรณ์ทั้งหมด sda กำลังบำรุงรักษา rootfs sda1 ไว้ล่วงหน้า

จากประสบการณ์ของฉันสิ่งนี้เกิดขึ้นในสถานการณ์:

1. HDD เสียหายจริงๆ ปัญหาการเขียนที่ส่งคืนจะขึ้นอยู่กับสภาพ HDD
2. เครื่องโฮสต์โอเวอร์โหลดแล้วงานเขียน HDD เสมือนแขกของ linux จะหมดเวลา
3. สายเคเบิล FC หรืออุปกรณ์ SAN (ดิสก์อาร์เรย์ผ่าน Fibre Channel) โอเวอร์โหลด
4. สูญเสียการเชื่อมต่อชั่วขณะผ่านทาง FC หรือ FCoE อาจจะแพ็คเก็ต FC ที่สูญหาย / หมดเวลา

ในสถานการณ์นี้อุปกรณ์อ่านเขียนได้อย่างแท้จริง แต่เคอร์เนล linux ทำเครื่องหมายว่าอุปกรณ์นี้เป็นแบบอ่านอย่างเดียวและใช้เป็นแบบอ่านอย่างเดียว นี่คือฟังก์ชั่นเคอร์เนลที่ทำเครื่องหมายเพื่อการป้องกันความเสียหาย

คำถามคือ วิธีการบอกเคอร์เนลด้วยตนเองอุปกรณ์ hdd block ทำงานตามปกติ?

ใช้สิ่งนี้เคอร์เนลให้บริการอุปกรณ์แบบอ่านอย่างเดียวเช่น 'CD-ROM' และไม่มีคำสั่งอื่นที่มีโอกาสทำงานอย่างถูกต้องรวมถึงการเมานต์ / เมานต์ -o อ่าน - เขียน fsck และอื่น ๆ

ผู้ใช้งานที่ไม่สามารถใช้งานได้มีคุณสมบัติเป็นสแปมจากผู้ที่ต้องการความช่วยเหลือ แต่ไม่เข้าใจเกี่ยวกับลักษณะของปัญหา:

1. ลองนับใหม่เป็นอ่าน - เขียน (เป็นไปไม่ได้อุปกรณ์คือ RO)
2. fsck สิ่งนี้ (เพื่ออะไรอุปกรณ์คือ RO ไม่สามารถทำการซ่อมแซมได้)
3. 'ฉันไม่รู้' (ก่อนมีเหตุผล แต่ใช้ไม่ได้)
4. 'แทนที่อุปกรณ์ของคุณ' * (โดยปกติปัญหาจะเป็นอย่างอื่น)

มีใครมีสูตรสำหรับคำถามข้างต้นบ้างไหม เปลี่ยนสถานะสำหรับอุปกรณ์บล็อกที่เขียนได้ซึ่งเปลี่ยนจากสถานะอ่านอย่างเดียวเป็นอ่านเขียนได้หรือไม่ ในเวลานี้ดูเหมือนว่าไม่มีใครรู้วิธี

มันเป็นวิธีแก้ไขปัญหาบางอย่าง แต่มักจะ semiusable หรือใช้ไม่ได้:

1. ลบโมดูลรองรับการเข้าถึง hdd หรืออาร์เรย์หน่วยเก็บข้อมูลที่ระบุ น่าเสียดายที่อุปกรณ์ที่เสียหายจะเก็บ rootfs หรือไดรเวอร์เก็บทั้งอุปกรณ์และอุปกรณ์ที่เสียหายที่เก็บ rootfs ไว้
2. ลบ FC access to device และเข้าร่วมอีกครั้ง (fctools), ไม่ได้เป็นไปได้ทั้งหมด, ไม่ได้ใช้ allways
3. รีสตาร์ทเครื่อง WHOLE โดยปกติจะเป็นไปได้เท่านั้นและเราบังคับให้ทำ

ที่จุดที่ 1 และ 2 เราบอกกับเคอร์เนลว่าเรายกเลิกการเชื่อมต่ออุปกรณ์อย่างสมบูรณ์และเชื่อมต่อกับมันอีกครั้ง เคอร์เนลได้รับการยอมรับว่าเป็นการเข้าร่วมอุปกรณ์การทำงานใหม่อย่างถูกต้อง เราสามารถจำลองสิ่งนี้ได้โดยใช้อุปกรณ์ USB และถอดปลั๊กไฟชั่วคราว จุดที่ 3 เป็นโอกาสสุดท้ายและมักจะได้ผล แต่ทำไมเราต้องรีสตาร์ททั้งหมด? น่าเสียดายที่ทุกจุดเราสูญเสียการอัปเดตวารสารและบัฟเฟอร์สกปรกทั้งหมด

สังเกตว่าในสถานการณ์เดียวกันฉันไม่มีปัญหากับ Windows (เดสก์ท็อปและเซิร์ฟเวอร์)

ลองด้วยblockdev --setrwหรือhdparm -r 0

เช่นเดียวกับ Jose Luis Martin แนะนำให้ใช้ blockdev, 2cent ของฉันคือทำ rw ใหม่และ forcefsck

(สมมติว่า sda เป็นดิสก์ของคุณ)

blockdev --setrw /dev/sda
mount /dev/sda -o remount,rw
touch /forcefsck

ตรวจสอบหน้าวิกินี้โดยอธิบายข้อผิดพลาดที่เกิดขึ้นจาก libata:

https://ata.wiki.kernel.org/index.php/Libata_error_messages

จากสิ่งที่ฉันเห็นด้านบนคุณมีปัญหาการหมดเวลาและตามเอกสารที่กล่าวถึง:

คอนโทรลเลอร์ไม่สามารถตอบกลับคำสั่ง ATA ที่ใช้งานอยู่ นี่อาจเป็นสาเหตุจำนวนเท่าใดก็ได้ ส่วนใหญ่มักเกิดจากข้อผิดพลาดของระบบย่อยขัดจังหวะที่ไม่เกี่ยวข้อง (ลองบูตด้วย 'pci = nomsi' หรือ 'acpi = off' หรือ 'noapic') ซึ่งไม่สามารถส่งสัญญาณขัดจังหวะเมื่อเราคาดหวังว่าจะได้รับหนึ่งจากฮาร์ดแวร์

คุณอาจต้องการที่จะปิดการใช้งาน ACPI (ตรวจสอบวิธีการที่ขึ้นอยู่กับ distro ของคุณ) หรือตรวจสอบเคอร์เนลของคุณเพื่อหาข้อบกพร่องที่รู้จัก

รีบูตใน windows 10 ไปที่ตัวเลือกพลังงานและปิดการปิดอย่างรวดเร็ว จากนั้นรีบูตเครื่องไปยัง linux ..gbamm ทั้งหมดเป็นเรื่องปกติ

การปิดอย่างรวดเร็วใน windows 10 จะไฮเบอร์เนตไฟล์บางส่วนและใช้งานบางส่วนของไดรฟ์ ดังนั้น linux จึงเห็นว่าไม่ว่าง