当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 一切顺利，现在我把它从下面抽出来。
[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
好的，不是自动执行，我只是给它一点点推动：
[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
Noooooooooo。
我已经尝试了各种不同的mount / tune2fs / dmsetup命令，我无法弄清楚如何让它解除块设备的写保护。 重新启动会解决它，但我宁愿在网上做。 一个小时的谷歌search没有得到我的任何地方。 保存我的ServerFault。
我刚刚遇到了这个问题，并通过重新启动解决了它，但经过进一步的调查，似乎发出以下命令可能会解决它。
echo running > /sys/block/device-name/device/state
我想你可能想看看本文档中的第25.14.4节： 改变在线逻辑单元的读/写状态 ，但是，我build议重启。
尝试使用：
mount -o remount,rw /mnt/fo
我是首先防止这个问题的粉丝。 大多数企业UNIX机器将像永远一样重试文件系统操作。 您作为pipe理员需要在调整MPIOconfiguration之前做一些功课。 如果您的应用程序应该等到设备返回到可用状态，那么这是一个解决scheme。 在你的/etc/multipath.conf中，确保你所关心的设备types的“no_path_retry”设置为“queue”。 设置这将导致失败的I / O队列，直到有一个有效的path。 我们已经为EMC Symmtrix / DMX盒子在特定条件下驱动/控制器/ srdfpath故障/恢复工作。 当你想在失败期间手动失败时，设备会变得更加复杂，因为你需要使用像dmsetup这样的工具来刷新/失败I / O或临时更改multipath.conf文件和重新扫描设备等。
这种方法无数次地节省了我们的培根，也是我们在多机箱/多供应商SAN上为数百个盒子提供复制灾难恢复标准的标准。
只是想我可能会和大家分享一下。 保重。
我遇到了一些问题，我在逻辑，多path设备的子驱动器上使用带-r选项的hdparm解决了这个问题。
-r获取/设置设备的只读标志。 设置后，Linux不允许在设备上进行写入操作。
您是否认为这与本文档中标题为“ 为什么我的存储区域networking（SAN）上的ext3文件系统反复变为只读 ？”相关？
这是一篇相当古老的文章，正在谈论光纤通道，但可能与您的问题有关。
文件系统损坏？ 尝试：
dumpe2fs /dev/c/c | grep Filesystem\
如果清理出错，则需要扫描并清理。
对于大中型SAN来说，Linux根本无法应对。 你必须小心谨慎地调整IO超时和多path超时处理，它们几乎都是桌面就绪的默认值。
（记住“拒绝IO到死器件”？）