web-dev-qa-db-ja.com

ディスクエラーから読み取り専用でマウントされた後、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

「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

わかりました。自動的には実行しません。少しプッシュします。

[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を保存してください。

centosmountext3read-only
18
cagenut

最近この問題に遭遇し、再起動して解決しましたが、さらに調査した結果、次のコマンドを発行すると問題が解決するようです。

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

セクション25.14.4を見てください：これでオンライン論理ユニットの読み取り/書き込み状態の変更 document ただし、再起動することをお勧めします。

6
specialKevin

使ってみてください：

mount -o remount,rw /mnt/fo
3
deleted

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

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

2
c4f4t0r

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

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

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

2
TomF

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

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

1
The Unix Janitor

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

dumpe2fs /dev/c/c | grep Filesystem\

エラーが発生した場合は、スキャンしてクリーニングする必要があります。

0
codycook