ディスクエラーから読み取り専用でマウントされた後、ext3 fs readwriteを再マウントするにはどうすればよいですか？

SANでext3がディスク書き込みエラーを検出し、ファイルシステムを読み取り専用で再マウントするために何か問題が発生した場合の比較的一般的な問題。SANが修正された場合にのみ、リブートせずにファイルシステムを読み書き可能に再マウントする方法がわかりません。

見よ：

[root@localhost ~]# multipath -ll
mpath0 (36001f93000a310000299000200000000) dm-2 XIOTECH,ISE1400
[size=1.1T][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=2][active]
\_ 1:0:0:1 sdb 8:16  [active][ready]
\_ 2:0:0:1 sdc 8:32  [active][ready]
[root@localhost ~]# mount /dev/mapper/mpath0 /mnt/foo
[root@localhost ~]# touch /mnt/foo/blah

いいですね、今、その下からLUNを抜き取ります。

[root@localhost ~]# touch /mnt/foo/blah
[root@localhost ~]# touch /mnt/foo/blah
touch: cannot touch `/mnt/foo/blah': Read-only file system
[root@localhost ~]# tail /var/log/messages
Mar 18 13:17:33 localhost multipathd: sdb: tur checker reports path is down
Mar 18 13:17:34 localhost multipathd: sdc: tur checker reports path is down
Mar 18 13:17:35 localhost kernel: Aborting journal on device dm-2.
Mar 18 13:17:35 localhost kernel: Buffer I/O error on device dm-2, logical block 1545
Mar 18 13:17:35 localhost kernel: lost page write due to I/O error on dm-2
Mar 18 13:17:36 localhost kernel: ext3_abort called.
Mar 18 13:17:36 localhost kernel: EXT3-fs error (device dm-2): ext3_journal_start_sb:   Detected aborted journal                      
Mar 18 13:17:36 localhost kernel: Remounting filesystem read-only

読み取り専用であるとのみ考えており、実際には存在しません。

[root@localhost ~]# multipath -ll
sdb: checker msg is "tur checker reports path is down"
sdc: checker msg is "tur checker reports path is down"
mpath0 (36001f93000a310000299000200000000) dm-2 XIOTECH,ISE1400
[size=1.1T][features=0][hwhandler=0][rw]
\_ round-robin 0 [prio=0][enabled]
 \_ 1:0:0:1 sdb 8:16  [failed][faulty]
 \_ 2:0:0:1 sdc 8:32  [failed][faulty]
[root@localhost ~]# ll /mnt/foo/
ls: reading directory /mnt/foo/: Input/output error
total 20
-rw-r--r-- 1 root root     0 Mar 18 13:11 bar

その「バー」ファイルがそこに存在することをまだ覚えている方法...謎ですが、今は重要ではありません。次に、LUNを再表示します。

[root@localhost ~]# tail /var/log/messages
Mar 18 13:23:58 localhost multipathd: sdb: tur checker reports path is up
Mar 18 13:23:58 localhost multipathd: 8:16: reinstated
Mar 18 13:23:58 localhost multipathd: mpath0: queue_if_no_path enabled
Mar 18 13:23:58 localhost multipathd: mpath0: Recovered to normal mode
Mar 18 13:23:58 localhost multipathd: mpath0: remaining active paths: 1
Mar 18 13:23:58 localhost multipathd: dm-2: add map (uevent)
Mar 18 13:23:58 localhost multipathd: dm-2: devmap already registered
Mar 18 13:23:59 localhost multipathd: sdc: tur checker reports path is up
Mar 18 13:23:59 localhost multipathd: 8:32: reinstated
Mar 18 13:23:59 localhost multipathd: mpath0: remaining active paths: 2
Mar 18 13:23:59 localhost multipathd: dm-2: add map (uevent)
Mar 18 13:23:59 localhost multipathd: dm-2: devmap already registered
[root@localhost ~]# multipath -ll
mpath0 (36001f93000a310000299000200000000) dm-2 XIOTECH,ISE1400
[size=1.1T][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=2][enabled]
 \_ 1:0:0:1 sdb 8:16  [active][ready]
 \_ 2:0:0:1 sdc 8:32  [active][ready]

いいね？そこに[rw]と書かれています。そんなに早くない：

[root@localhost ~]# touch /mnt/foo/blah
touch: cannot touch `/mnt/foo/blah': Read-only file system

OK、自動ではありません。少しプッシュするだけです。

[root@localhost ~]# mount -o remount /mnt/foo
mount: block device /dev/mapper/mpath0 is write-protected, mounting read-only

あなたは地獄です：

[root@localhost ~]# mount -o remount,rw /mnt/foo
mount: block device /dev/mapper/mpath0 is write-protected, mounting read-only

うん

さまざまな種類のmount / tune2fs / dmsetupコマンドを試しましたが、ブロックデバイスの書き込み禁止フラグを解除する方法がわかりません。再起動すると修正されますが、私はむしろオンラインでそれをしたいです。1時間のグーグル検索でも、どこにも行きませんでした。ServerFaultを保存してください。

私は最近この問題に遭遇し、再起動することで解決しましたが、さらに調査した結果、次のコマンドを発行すると問題が解決する可能性があります。

echo running > /sys/block/device-name/device/state

このドキュメントのセクション25.14.4：オンライン論理ユニットの読み取り/書き込み状態の変更をご覧になるとよいと思いますが、再起動することをお勧めします。

使用してみてください：

mount -o remount,rw /mnt/fo

私はそもそも問題を防ぐことが好きです。ほとんどのエンタープライズUNIXボックスは、永久にファイルシステム操作を再試行します。管理者は、MPIO構成を調整する前に宿題をする必要があります。デバイスが使用可能な状態に戻るまでアプリケーションを待機する必要がある場合は、次の解決策があります。/etc/multipath.confで、関心のあるデバイスタイプに「no_path_retry」の設定が「queue」に設定されていることを確認してください。これを設定すると、有効なパスが見つかるまで、失敗したI / Oがキューに入れられます。これは、EMC Symmtrix / DMXボックスで、ドライブ/コントローラー/ srdfパスの障害/回復の特定の条件下でのしゃっくりについて機能するために行いました。

このアプローチにより、ベーコンは数え切れないほど節約され、災害復旧用のレプリケーションを備えたマルチキャビネット/マルチベンダーSANの数百のボックスの標準となっています。

皆さんと共有できると思っただけです。気を付けて。

いくつかの問題がありましたが、-r論理的なマルチパスデバイスのサブドライブでhdparmオプションを使用して解決しました。

-rデバイスの読み取り専用フラグを取得/設定します。設定すると、Linuxはデバイスでの書き込み操作を許可しません。

このドキュメントの「ストレージエリアネットワーク（SAN）上のext3ファイルシステムが繰り返し読み取り専用になるのはなぜですか？」というセクションに関連していると思いますか？

これはかなり古い記事であり、ファイバーチャネルについて説明していますが、問題に関連している可能性があります。

ファイルシステムの破損？試してください：

dumpe2fs /dev/c/c | grep Filesystem\

エラーできれいになったら、スキャンしてきれいにする必要があります。

Linuxは、中規模から大規模のSANに十分に対応できません。いくつかの注意を払い、IOタイムアウトとマルチパスタイムアウトの処理を微調整する必要があります。これらはすべてデスクトップ対応のデフォルト値です。

（「デッドデバイスへのIOの拒否」を覚えていますか？）