Linux，如何在暫時崩潰後從 ReadOnly 更改 HDD 狀態？

目前沒有解決這個問題的辦法。

通常在讀取或寫入塊設備出現問題後，核心決定將整個設備的標誌切換為只讀。在此之後，對該設備上的任何分區/文件系統的任何寫入都會導致將其與設備狀態一起切換為只讀，因為任何寫入都是不可能的。

來自 dmesg 的範例，這是在碎片整理獲取來賓設備映像時使用 VirtualBox 在 windows8 上模擬來賓 linux：

[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

因為保持 rootfs sda1 的整個設備 sda 是只讀的。

根據我的經驗，這發生在以下情況：

1. 硬碟真的壞了。返回的寫入問題取決於硬碟狀況
2. 主機過載，然後 linux guest 虛擬硬碟寫入超時
3. FC 電纜或 SAN 設備（光纖通道上的陣列磁碟）過載
4. 通過 FC 或 FCoE 暫時失去連接。可能失去/超時的 FC 數據包

在這種情況下，設備確實是可讀寫的，但 linux 核心在內部將此設備標記為只讀並用作只讀。這是用於防止損壞的核心功能，但它僅在 1. 點可用。

問題是。如何手動告訴核心，硬碟塊設備正常執行？

沒有這個，核心將設備作為只讀服務，如“CD-ROM”，並且沒有其他命令有機會正常工作，包括 mount/remount -o read-write 、 fsck 等。

無法使用的答案，確實是來自想要幫助但不了解問題性質的人的垃圾郵件：

1. 嘗試重新掛載為讀寫（不可能，設備是RO）
2. fsck this (what for? device is RO, no repair is possible)
3. “我不知道”（首先是有意義的，但無法使用）
4. ‘更換你的設備’ *（通常問題是別的）

有人有上述問題的公式嗎？可寫塊設備的開關標誌，將其從只讀狀態恢復為讀寫狀態？在這個時候似乎沒有人知道如何。

這是一些解決方法，但通常是半可用或不可用：

1. 移除模組支持訪問指定的硬碟或儲存陣列。不幸的是，通常損壞的設備會保留 rootfs，或者驅動程序會同時保留損壞的設備和保留 rootfs 的設備
2. 刪除對設備的 FC 訪問並再次加入（fctools），並非總是可行，也並非總是有效。
3. 重新啟動整台機器。通常只有這一切都是可能的，我們總是被迫這樣做。

在第 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

引用自：https://unix.stackexchange.com/questions/74090