Причина повреждения файловой системы EXT4 гостевой системы Hyper-V

У нас было второе повреждение раздела ext4 за относительно короткое время, и ext4 предположительно очень надежен. Поскольку это виртуальная машина, и хост, предоставляющий ресурсы, не обнаружил ошибок диска, потери питания или чего-то подобного, я хочу сейчас исключить аппаратные ошибки.

Поэтому мне интересно, есть ли у нас такая необычная установка (гость CoreOS под хостом Hyper-V), такая необычная рабочая нагрузка (контейнеры Docker для Nginx, Gitlab, Redmine, MediaWiki, MariaDB) или плохая конфигурация. Любой ввод / предложение приветствуются.

Исходное сообщение об ошибке (во втором случае) было:

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 run обнаружил много ошибок (не думал вести журнал) и поместил около 357 МБ в lost+found для раздела 2 ТБ с объемом данных около 512 ГБ. После этого ОС все еще загружается, поэтому потерянные части, похоже, лежат в контейнерах пользовательских данных или докеров.

Вот еще несколько подробностей о затронутой системе:

$ 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 Server 2016
• диск основан на файле виртуального диска (в отличие от физического диска)
• диск настроен как динамический (т.е. растущий)
• на виртуальной машине есть несколько снимков / точек восстановления. Я не уверен, переключает ли это образ диска с динамического на разностный (?)