主页 / server / 问题 / 1020531
Accepted
Olaf Mandel
Asked: 2020-06-09 06:23:34 +0800 CST

Hyper-V 来宾的 EXT4 文件系统损坏的原因

  • 772

我们在相对较短的时间内对 ext4 分区进行了第二次损坏，并且 ext4 据说非常可靠。由于这是一个虚拟机，并且提供资源的主机没有看到磁盘错误或断电等，我想暂时排除硬件错误。

所以我想知道我们是否有如此不寻常的设置（Hyper-V 主机下的 CoreOS 来宾）、如此不寻常的工作负载（Nginx、Gitlab、Redmine、MediaWiki、MariaDB 的 Docker 容器）或错误的配置。欢迎任何意见/建议。

原始错误消息（在第二种情况下）是：

Jun 05 02:00:50 localhost kernel: EXT4-fs error (device sda9): ext4_lookup:1595: inode #8347255: comm git: deleted inode referenced: 106338109
Jun 05 02:00:50 localhost kernel: Aborting journal on device sda9-8.
Jun 05 02:00:50 localhost kernel: EXT4-fs (sda9): Remounting filesystem read-only

此时，e2fsck运行发现很多错误（没有考虑保留日志），并lost+found为一个 2TB 的分区放置了大约 357MB，上面有大约 512GB 的数据。此后操作系统仍会启动，因此丢失的部分似乎位于用户数据或 docker 容器中。

以下是有关受影响系统的更多详细信息：

$ uname -srm
Linux 4.19.123-coreos x86_64
$ sudo tune2fs -l /dev/sda9
tune2fs 1.45.5 (07-Jan-2020)
Filesystem volume name:   ROOT
Last mounted on:          /sysroot
Filesystem UUID:          04ab23af-a14f-48c8-af59-6ca97b3263bc
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg inline_data sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Remount read-only
Filesystem OS type:       Linux
Inode count:              533138816
Block count:              536263675
Reserved block count:     21455406
Free blocks:              391577109
Free inodes:              532851311
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Reserved GDT blocks:      15
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         32576
Inode blocks per group:   1018
Flex block group size:    16
Filesystem created:       Tue Sep 11 00:02:46 2018
Last mount time:          Fri Jun  5 15:40:01 2020
Last write time:          Fri Jun  5 15:40:01 2020
Mount count:              3
Maximum mount count:      -1
Last checked:             Fri Jun  5 08:14:10 2020
Check interval:           0 (<none>)
Lifetime writes:          79 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      595db5c2-beda-4f32-836f-ee025416b0f1
Journal backup:           inode blocks

更新：

以及有关主机设置的更多详细信息：

  • 使用 Hyper-V 服务器 2016
  • 磁盘基于虚拟磁盘文件（与物理磁盘相反）
  • 磁盘设置为动态（即增长）
  • 虚拟机上有几个快照/还原点。我不确定这是否将磁盘映像从动态切换到差异（？）
filesystems hyper-v corruption ext4 coreos

1 个回答

  1. Best Answer

    孤立的 inode 包含的数据是一个非常棘手的问题。为什么存储系统会做这样的事情要困难得多。

    首先，做好事件响应。检查这些工作负载是否有计划外停机时间。评估您的恢复选项：在单独的存储、备份、其他数据副本上的任何 DR 环境。

    考虑在更改任何内容之前备份 VHD。允许撤消您的操作，也许您可​​以让支持人员检查损坏的音量。

    确定哪些数据受到影响。

    • 在那些丢失的 inode 上运行file以猜测它们的格式。打开并检查它们的内容。

    • 对应用程序数据运行完整性检查。

    检查存储和计算系统中的所有内容。

    • 存储阵列卷状态：在线，空闲容量
    • 单个物理磁盘的运行状况
    • 在访客日志中搜索与相关的每条消息EXT4
    • 运行 Windows 最佳实践分析器。在评论中，我们发现了不使用 VHD 动态磁盘的建议。

    可能没有明显的原因。即便如此，请考虑转移到不同的系统以排除硬件问题。如果您在不同硬件上拥有 DR 系统，请考虑切换到该系统。或者尝试更换较小的组件，例如阵列中的磁盘。或者将 VM 迁移到不同的计算主机。

    • 1

相关问题