☰

因磁盘错误而以只读方式挂载 ext3 fs 读写后，如何重新挂载？

tag-icon • tag-icon centos mount ext3 read-only
因磁盘错误而以只读方式挂载 ext3 fs 读写后，如何重新挂载？

当 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。

答案1

我最近遇到了这个问题并通过重新启动解决了它，但经过进一步调查后发现发出以下命令可能会解决这个问题。

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

我想你可能想看看查看第 25.14.4 节：更改联机逻辑单元的读/写状态在本文档中但是，我建议重新启动。

答案2

尝试使用：

mount -o remount,rw /mnt/fo

答案3

我支持从一开始就预防这个问题。大多数企业 UNIX 盒会像永远一样重试文件系统操作。作为管理员，您需要在调整 MPIO 配置之前做一些功课。如果您的应用程序应该等到设备恢复到可用状态，那么这里有一个解决方案。在您的 /etc/multipath.conf 中，确保您关心的设备类型的“no_path_retry”设置为“queue”。设置此项将导致失败的 I/O 排队，直到有有效路径。我们已经为我们的 EMC Symmtrix/DMX 盒做了这件事，以解决某些条件下驱动器/控制器/srdf 路径故障/恢复的故障。当您想在故障期间手动使设备故障时，情况会变得更加复杂，因为您需要使用 dmsetup 等工具来刷新/使 I/O 故障或临时更改 multipath.conf 文件并重新扫描设备……等等。

这种方法无数次拯救了我们，并且是我们在多机柜/多供应商 SAN 上数百个带有复制功能的盒子的标准，可用于灾难恢复。

我只是想和大家分享一下。保重。

答案4

你认为这与本文档中标题为为什么我的存储区域网络 (SAN) 上的 ext3 文件系统反复变为只读？

这是一篇相当古老的文章，讨论的是光纤通道，但可能与您的问题有关。

相关内容