現時点では、この問題に対する回答はありません。
通常、ブロックデバイスへの読み取りまたは書き込みに関するいくつかの問題の後、カーネルは、WHOLE DEVICEのフラグを読み取り専用に切り替えることを決定します。この後、このデバイスにあるパーティション/ファイルシステムへの書き込みは、書き込みが不可能であるため、デバイス状態とともに読み取り専用に切り替えます。
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は読み取り専用だからです。
私の経験では、これは次の状況で発生します。
- HDDは本当に破損しています。返される書き込みの問題は、HDDの状態に依存します
- ホストマシンが過負荷になり、Linuxゲスト仮想HDDの書き込みがタイムアウトになる
- FCケーブルまたはSANデバイス（ファイバーチャネル経由のアレイディスク）が過負荷
- FCまたはFCoEを介した瞬間的な接続の切断。FCパケットが失われた/タイムアウトした可能性があります
この状況では、デバイスは実際に読み書き可能ですが、Linuxカーネルはこのデバイスを内部的に読み取り専用としてマークし、読み取り専用として使用されます。これは損傷防止のために作られたカーネル機能ですが、1ポイントでのみ使用可能です。
質問です。手動でカーネルに通知するには、hddブロックデバイスは正常に動作しますか？
これを除けば、カーネルは「CD-ROM」のような読み取り専用としてデバイスを提供し、mount / remount -o read-write、fsckなどを含む他のコマンドは適切に動作する機会がありません。
役に立たないが、問題の性質については理解していない人々からのスパムとして本当に認定された、使用不可能な回答者：
- 読み書き可能として再マウントしてください（不可能、デバイスはROです）
- fsckこれ（何のためですか？デバイスはROで、修復は不可能です）
- 「わからない」（最初は意味があるが、使用できない）
- 「デバイスを交換してください」*（通常、問題は別のものです）
上記の質問の式はありますか？読み取り専用から読み取り/書き込み状態に戻す書き込み可能なブロックデバイスのフラグを切り替えますか？現時点では、誰もその方法を知らないようです。
いくつかの回避策がありますが、通常は半使用可能または使用不可能です。
- 削除モジュールは、指定されたhddまたはストレージアレイへのアクセスをサポートします。残念ながら、通常は破損したデバイスがrootfsを保持するか、ドライバーが破損したデバイスとrootfsを保持するデバイスの両方を保持します
- デバイスへのFCアクセスを削除し、これに再度参加してください（fctools）。
- 完全なマシンを再起動します。通常、これのみが常に可能であり、私たちは常に強制されます。
ポイント1および2で、カーネルにデバイスを完全に切断し、再度接続することを伝えます。カーネルは、これを適切に動作する新しいデバイスに参加するものとして認識しました。USBデバイスと瞬間的な電源切断を使用して、これをシミュレートできます。ポイント3はラストチャンスであり、通常は機能します。しかし、なぜすべてを再起動する必要があるのでしょうか？残念ながら、すべての時点で、すべてのジャーナルの更新とダーティバッファが失われました。
同じ状況で、Windows（デスクトップとサーバー）に問題がないことに注意してください。