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

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