当 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。
我最近遇到了这个问题并通过重新启动解决了它,但经过进一步调查,似乎发出以下命令可能会解决它。
我想你可能想看看这个文档中的第 25.14.4 节:更改在线逻辑单元的读/写状态,但是,我建议重新启动。
尝试使用:
我喜欢从一开始就预防这个问题。大多数企业 UNIX 机器会像永远一样重试文件系统操作。作为管理员,您需要在调整 MPIO 配置之前做一些功课。如果您的应用程序应该等到设备返回可用状态,那么这里有一个解决方案。在您的 /etc/multipath.conf 中,确保您关心的设备类型的“no_path_retry”设置为“queue”。设置此项将导致失败的 I/O 排队,直到有一个有效的路径。我们已经为我们的 EMC Symmtrix/DMX 盒子完成了这项工作,以解决某些情况下驱动器/控制器/srdf 路径故障/恢复的问题。
这种方法无数次地拯救了我们的培根,并且是我们在多机柜/多供应商 SAN 上使用复制以进行灾难恢复的数百个盒子的标准。
只是想我可能会与大家分享。小心。
我遇到了一些问题,我使用hdparm和
-r
逻辑多路径设备的子驱动器选项解决了这个问题。您认为这与本文档中标题为“为什么我的存储区域网络 (SAN) 上的 ext3 文件系统反复变为只读”的部分有关吗?
这是一篇相当古老的文章,并且正在谈论光纤通道,但它可能与您的问题有关。
文件系统损坏?尝试:
如果清理出现错误,则需要扫描并清理。
Linux 根本无法很好地应对中大型 SAN。您必须注意并微调 IO 超时和多路径超时处理,它们几乎都是桌面就绪的默认设置。
(还记得“拒绝 IO 到死设备”吗?)