![调整文件系统大小后,意外损坏且无休止的 fsck](https://linux22.com/image/513513/%E8%B0%83%E6%95%B4%E6%96%87%E4%BB%B6%E7%B3%BB%E7%BB%9F%E5%A4%A7%E5%B0%8F%E5%90%8E%EF%BC%8C%E6%84%8F%E5%A4%96%E6%8D%9F%E5%9D%8F%E4%B8%94%E6%97%A0%E4%BC%91%E6%AD%A2%E7%9A%84%20fsck.png)
有问题的系统安装了 Debian Lenny,运行 2.6.27.38 内核。系统有 16GB 内存,8x1Tb 驱动器在 3Ware RAID 卡后面运行。
存储通过 LVM 管理,并且完全由 ext3 文件系统组成。
简洁版本:
- 运行一个分配了 1.7Tb 存储空间的 KVM 客户机。
- 客人的磁盘已满。
- 因此我们决定调整运行它的磁盘大小
我们非常熟悉 LVM 和 KVM,因此我们认为这将是一个轻松的操作:
- 停止 KVM 客户机。
- 扩大LVM分区的大小:“lvextend -L+500Gb ...”
- 检查文件系统:“e2fsck -f /dev/mapper/...”
- 调整文件系统大小:“resize2fs /dev/mapper/”
- 啟動客人。
客户机启动成功,运行“df”显示有额外的空间,但不久之后系统决定以只读方式重新挂载文件系统,而没有任何明确的错误迹象。
出于谨慎,我们关闭了客户机并再次运行文件系统检查,考虑到文件系统的新大小,我们预计这会需要一段时间,但是现在已经运行了 24 小时以上,并且没有迹象表明需要多长时间。
使用 strace 我可以看到 fsck 正在“执行操作”,同样运行“vmstat 1”我可以看到正在发生许多块输入/输出操作。
所以现在我的问题有三个:
有人遇到过类似的情况吗?一般来说,我们过去进行过这种调整,没有出现任何问题。
最可能的原因是什么?(3Ware 卡显示备用存储的 RAID 阵列正常,主机系统尚未重新启动,并且 dmesg 中没有任何重要/异常信息)
忽略 btrfs + ext3(还不够成熟,不值得信任),我们是否应该在将来将更大的分区放在不同的文件系统中,以避免这种损坏(无论原因是什么)或减少 fsck 时间?xfs 似乎是显而易见的候选者?
答案1
答案2
在这种情况下,可能是 virtio 和 1TB 的问题。
但对我来说,我在交替访问虚拟机外部(包括关闭此机器)和虚拟机内部的设备时遇到了类似的问题。如果您以直接访问方式访问虚拟机内部的块设备(例如在 kvm 配置中),这意味着没有缓存/缓冲区,而外部有缓冲区,您可能会遇到以下问题:
调整 vm 外部的设备大小,kvm 主机上的缓存/缓冲区会被填满。
启动虚拟机,识别(其他!)问题并关闭。
fsck 设备。
如果一切都变得很糟糕,您会从缓存中读取日期,但该日期已在之前运行的虚拟机中发生了更改,该虚拟机在没有缓冲区/缓存的情况下访问了设备!
我也做了很多 ext3 调整大小(自 2.6.18 以来),而且我一直在线这样做!据我所知,这使用内核函数来调整大小,而离线调整大小使用用户空间代码。
答案3
还要检查您的 KVM 缓存设置;KVM 可以不进行缓存、读取缓存、写回和写通缓存,这可能会让您感到意外。