web-dev-qa-db-ja.com

Linux、一時的なクラッシュ後にHDDの状態をReadOnlyから変更するにはどうすればよいですか？

現時点では、この問題に対する回答はありません。

通常、ブロックデバイスの読み取りまたは書き込みに問題が発生した後、カーネルは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は読み取り専用だからです。

私の経験では、これは次のような状況で発生します。

  1. HDDは本当に破損しています。返される書き込みの問題はHDDの状態に依存します
  2. ホストマシンが過負荷になり、Linuxゲスト仮想HDDの書き込みがタイムアウトになる
  3. FCケーブルまたはSANデバイス（ファイバーチャネル上のアレイディスク）が過負荷です
  4. FCまたはFCoEで一時的に接続が失われました。多分失われた/タイムアウトしたFCパケット

この状況では、デバイスは実際には読み取り/書き込み可能ですが、Linuxカーネルはこのデバイスを内部的に読み取り専用としてマークし、読み取り専用として使用されます。これはダメージ防止のために作られたカーネル機能ですが、1。ポイントでしか使えません。

質問です。手動でカーネルに伝える方法、hddブロックデバイスは正常に動作していますか？

これがなければ、カーネルはデバイスを「CD-ROM」のように読み取り専用として提供し、mount/remount -o read-writeやfsckなどを含む他のコマンドは正しく機能する機会がありません。

使いたくない回答者、本当に助けたいが、問題の性質については理解していない人々からのスパムとして認定されました：

  1. 読み取り/書き込みとして再マウントしてみてください（不可能、デバイスはR-Oです）
  2. fsck this（何のためですか？デバイスはR-Oであり、修復できません）
  3. 「わからない」（最初は意味があるが、使用できない）
  4. 「デバイスを交換してください」*（通常、問題は別の問題です）

上記の質問のための誰かが誰かいますか？読み取り専用から読み取り/書き込み状態に戻す書き込み可能ブロックデバイスのフラグを切り替えますか？現時点では誰もその方法を知らないようです。

これはいくつかの回避策ですが、通常は半使用可能または使用不可です。

  1. モジュールの削除は、指定されたhddまたはストレージアレイへのアクセスをサポートします。残念ながら、通常、破損したデバイスはrootfsを保持するか、またはドライバが破損したデバイスとrootfsを保持するデバイスの両方を保持します
  2. デバイスへのFCアクセスを削除し、これに再度参加します（fctools）。
  3. マシン全体を再起動します。通常、これは常に可能であり、私たちは常に強制されています。

1.と2.の時点で、デバイスを完全に切断して再度接続することをカーネルに通知します。カーネルはこれを新しい適切に動作するデバイスに参加するものとして認識しました。 USBデバイスを使用してこれをシミュレートし、一時的に電源を切ることができます。ポイント3.は最後のチャンスであり、通常は機能します。しかし、なぜすべてを再起動する必要があるのでしょうか。残念ながら、すべての時点で、すべてのジャーナルの更新とダーティバッファーが失われました。

通知、同じ状況でWindows（デスクトップおよびサーバー）に問題はありません。

linuxreadonlymount
19
Znik

blockdev --setrwまたはhdparm -r 0

13
Jose Luis Martin

ホセ・ルイス・マーティンがblockdevの使用を提案したように、私の2セントはrwとforcefsckを再マウントすることです

（sdaがディスクであると仮定）

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

このwikiページをチェックしてください、それはlibataによって投げられたエラーを説明します：

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

私が上記で見たものから、あなたはタイムアウトの問題を得ました、そして言及されたドキュメントによると：

コントローラはアクティブなATAコマンドに応答できませんでした。これにはさまざまな原因が考えられます。ほとんどの場合、これは無関係な割り込みサブシステムのバグ（ 'pci = nomsi'または 'acpi = off'または 'noapic'で起動してみてください）が原因であり、ハードウェアからの割り込みを予期していたときに割り込みを配信できませんでした。

ACPIを無効にする（ディストリビューションに基づく方法を確認する）か、既知のバグがないかカーネルを確認し、最新でない場合は更新する（またはダウングレードする）ことができます。

2
UnX

Windows 10で再起動し、電源オプションに移動して、高速シャットダウンをオフにします。その後、linux ..gbammで再起動します。

windows 10での高速シャットダウンにより、一部のファイルが休止状態になり、ドライブが部分的に使用されます。したがって、Linuxは同じようにビジーです。

0
awas