☰

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

tag-icon • tag-icon linux readonly mount
Linux、一時的にクラッシュした後に HDD の状態を ReadOnly から変更するにはどうすればいいですか?

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

通常、ブロック デバイスの読み取りまたは書き込みで問題が発生すると、カーネルはデバイス全体のフラグを読み取り専用に切り替えることを決定します。この後、このデバイスにあるパーティション/ファイル システムへの書き込みは、書き込みが不可能になるため、デバイスの状態とともに読み取り専用に切り替わります。

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

ルートファイルシステム 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. 読み取り/書き込みとして再マウントしてみてください (不可能、デバイスは RO です)
  2. これを fsck します (何のためですか? デバイスは RO なので修復は不可能です)
  3. 「分かりません」（最初は意味は通じたが、使えない）
  4. 「デバイスを交換してください」*(通常は別の問題です)

上記の質問に対する答えを知っている人はいますか? 書き込み可能なブロック デバイスのスイッチ フラグを使用して、読み取り専用状態から読み取り/書き込み状態に戻す方法は? 現時点では、誰もその方法を知らないようです。

いくつかの回避策がありますが、通常は半分しか使用できないか、使用できません。

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

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

同じ状況では、Windows (デスクトップとサーバー) では問題がないことに注意してください。

答え1

blockdev --setrwまたは試すhdparm -r 0

答え2

Jose Luis Martinがblockdevの使用を提案したように、私の意見としては、rwを再マウントしてforcefsckを実行することです。

(sda がディスクであると仮定)

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

答え3

この wiki ページを確認してください。libata によってスローされるエラーについて説明されています。

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

上記から判断すると、タイムアウトの問題が発生しており、ドキュメントに記載されているとおりです。

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

ACPI を無効にするか (ディストリビューションに応じて方法を確認してください)、カーネルに既知のバグがないか確認し、最新でない場合は更新 (またはダウングレード) することをお勧めします。

答え4

###こんにちは、次のコマンドが役立ちます。ただし、実行中のドライブのルート ファイルシステムをアンマウントしたり変更したりするのは安全ではありません。代わりに、起動可能なデバイスからシステムを起動してください。

  1. システム上のドライブを見つける
$ mount | grep /dev/
  1. ドライブをアンマウントする
$ sudo umount <your-mount-point-name>
  1. 次のコマンドのいずれかを使用してファイルシステムをチェックし、修復します。

###ext4デバイスの場合

$ sudo fsck.ext4 -f /dev/sda1

###DOSデバイスの場合

$ sudo dosfsck -a /dev/sda1

###または、単にfsckコマンドを実行することもできます。

$ sudo fsck /dev/sda1
  1. デバイスを再マウントする
$ sudo mkdir <your-mount-point-name>

これにより、新しいマウント ポイントが作成されます。次に、次のコマンドを実行します。

$ sudo mount -o rw,uid=1000,gid=1000,user,exec,umask=003,blksize=4096 /dev/sdc1 /media/<your-mount-point-name>

これで準備完了です。ただし、コマンドの詳細については、ベルドゥング

関連情報