Hyper-V 來賓的 EXT4 文件系統損壞的原因

我們在相對較短的時間內對 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
• 磁碟基於虛擬磁碟文件（與物理磁碟相反）
• 磁碟設置為動態（即增長）
• 虛擬機上有幾個快照/還原點。我不確定這是否將磁碟映像從動態切換到差異（？）

孤立的 inode 包含的數據是一個非常棘手的問題。為什麼儲存系統會做這樣的事情要困難得多。

首先，做好事件響應。檢查這些工作負載是否有計劃外停機時間。評估您的恢復選項：在單獨的儲存、備份、其他數據副本上的任何 DR 環境。

考慮在更改任何內容之前備份 VHD。允許撤消您的操作，也許您可以讓支持人員檢查損壞的音量。

確定哪些數據受到影響。

• 在那些失去的 inode 上執行file以猜測它們的格式。打開並檢查它們的內容。

• 對應用程序數據執行完整性檢查。

  • GitLab 包含git fsck在一個任務中。鑑於 syslog 消息表明 git 二進制訪問了問題數據，尤其相關。
  • 在您的 DBMS 上執行檢查。

檢查儲存和計算系統中的所有內容。

• 儲存陣列卷狀態：線上，空閒容量
• 單個物理磁碟的執行狀況
• 在訪客日誌中搜尋與相關的每條消息EXT4
• 執行 Windows 最佳實踐分析器。在評論中，我們發現了不使用 VHD 動態磁碟的建議。

可能沒有明顯的原因。即便如此，請考慮轉移到不同的系統以排除硬體問題。如果您在不同硬體上擁有 DR 系統，請考慮切換到該系統。或者嘗試更換較小的組件，例如陣列中的磁碟。或者將 VM 遷移到不同的計算主機。

引用自：https://serverfault.com/questions/1020531