当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命令，但无法弄清楚如何取消将块设备标记为写保护。重新启动将解决该问题，但我宁愿在线进行。一个小时的谷歌搜索也使我无处可去。救我ServerFault。
3
嗯，有几个问题“当SAN出问题时，这是一个相对普遍的问题”， 为什么您的SAN如此不可靠，我会先检查一下？您是否尝试过用umount卸载，然后再次安装？是否有充分的理由为什么需要重新安装？我通常只需要在维护之后重新挂载我的根文件系统。
—
Unix管理员
umount在打开的文件句柄上弹跳，这些句柄通常来自您宁可理智退出的进程。
—
basketnut
我有一个类似的问题，在SAN问题之后，VM磁盘是只读的，尝试重新挂载会导致OP中出现相同的错误。VM在带有光纤通道存储的esxi 4.1上。重新启动VM可解决此问题。我个人不认为这与多路径有关。当然，必须有一种无需重新启动就可以修复的方法，尤其是由于某些服务（Apache）倾向于在只读FS上继续运行。
—
威尔
我来这里是为了寻找解决自己的问题（不同的是，磁盘损坏）的解决方案。我笑了。为“你到底是
—
谁
我有与此完全相同的问题，但是我正在使用LVM。相同的lvdisplay会给我“在40961973处的0以后读取失败，449197309952：输入/输出错误”，直到我执行“ multipath -r”为止，然后LVM开始正确显示所有内容而没有错误。不过，我仍然无法重新安装该分区。表示设备正忙，也无法卸载。如果我关闭了使用该设备的所有进程，则可以卸载然后成功重新安装，但是我更希望能够以读写方式重新安装设备，因为我应该能够...
—
mpontes