我如何才能找到 ext3 文件系统损坏的原因?

我如何才能找到 ext3 文件系统损坏的原因?

我们有一个运行 CentOS 5.8 虚拟机的 VMware vSphere 5 环境。在过去两周内,我们遇到了五起虚拟机文件系统损坏的事件,需要使用 fsck 进行修复。

以下是我们在日志中看到的内容:

Nov 14 14:39:28 hostname kernel: EXT3-fs error (device dm-2): htree_dirblock_to_tree: bad entry in directory #2392098: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0
Nov 14 14:39:28 hostname kernel: Aborting journal on device dm-2.
Nov 14 14:39:28 hostname kernel: __journal_remove_journal_head: freeing b_committed_data
Nov 14 14:39:28 hostname last message repeated 4 times
Nov 14 14:39:28 hostname kernel: ext3_abort called.
Nov 14 14:39:28 hostname kernel: EXT3-fs error (device dm-2): ext3_journal_start_sb: Detected aborted journal
Nov 14 14:39:28 hostname kernel: Remounting filesystem read-only
Nov 14 14:39:28 hostname kernel: EXT3-fs error (device dm-2): htree_dirblock_to_tree: bad entry in directory #2392099: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0
Nov 14 14:31:17 hostname ntpd[3041]: synchronized to 194.238.48.2, stratum 2
Nov 14 15:00:40 hostname kernel: EXT3-fs error (device dm-2): htree_dirblock_to_tree: bad entry in directory #2162743: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0
Nov 14 15:13:17 hostname kernel: __journal_remove_journal_head: freeing b_committed_data

问题似乎当我们从另一台服务器 rsync 应用程序数据时,会发生这种情况。到目前为止,我们无法重现该问题,也无法确定根本原因。

在我们的几台服务器出现此问题后,我们认为模板存在问题,因此我们废弃了从模板克隆的所有虚拟机,销毁了模板,并从头开始构建了一个新模板,并从新下载的 CentOS ISO 进行安装。

我们使用 HP EVA SAN 作为数据存储,在第一次出现问题后,我们从 4400 迁移到 6300。自从迁移和重建新虚拟机以来,我们已经两次遇到此问题。在一台虚拟机上,我们关闭服务器,删除两个虚拟 CPU,然后重新启动,问题几乎立即出现。在另一台虚拟机上,我们重新启动它,半小时后问题再次出现。

如能提供任何正确的建议或指引,我将不胜感激。

答案1

这里有一份关于 HP EVA 的 KB,特别是如果您使用的是 Round Robin PSP。首先,您应该检查 vmkernel.log 以检查是否存在存储错误。 相关知识库条目 (pdf)

为了优化 EVA 阵列性能,HP 建议将默认的循环负载平衡 IOPS 值更改为 1。必须在 ESX4.x 上使用以下命令对每个 Vdisk 执行此更新:

esxcli nmp roundrobin setconfig -t iops -I 1 -d naa.xxxxxxxxx

对于 ESXi5:

for i in `esxcli storage nmp device list | grep naa.600` ; do esxcli storage nmp psp roundrobin deviceconfig set -t iops –I 1 -device $i; done

答案2

如果问题仅在您将数据从一台服务器同步到另一台服务器时才会重现,则意味着问题与从内核的角度来看数据一致性的方式有关。如果内核认为文件系统即将损坏或已经损坏,它将把文件系统变为只读。

我对 HP EVA 不太了解,但它是否有电池支持的写入缓存。如果有,您可以禁用磁盘写入缓存并使用 SAN 阵列写入缓存吗?为此,使用 mount -o barrier=1 进行安装,看看是否看到任何改进。

我有一种直觉,认为这与存储有关,而不是任何文件系统故障。我不确定如何证明这一点,但我见过的大多数有关文件系统损坏的案例都以某种方式或某种方式涉及存储作为罪魁祸首,如果不是主要原因的话。

相关内容