Raison de la corruption du système de fichiers EXT4 de l'invité Hyper-V

Nous avons eu notre deuxième corruption d'une partition ext4 en un temps relativement court et ext4 est censé être très fiable. Comme il s'agit d'une machine virtuelle et que l'hôte qui fournit les ressources n'a pas constaté d'erreur de disque ou de perte de puissance, je veux exclure les erreurs matérielles pour le moment.

Je me demande donc si nous avons une configuration inhabituelle (un invité CoreOS sous un hôte Hyper-V), une charge de travail inhabituelle (conteneurs Docker de Nginx, Gitlab, Redmine, MediaWiki, MariaDB) ou une mauvaise configuration. Toute contribution / suggestion serait la bienvenue.

Le message d'erreur original (dans la deuxième instance) était :

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

À ce stade, un e2fsck a trouvé beaucoup d'erreurs (je n'ai pas pensé à garder le journal) et a placé environ 357MB dans le fichier lost+found pour une partition de 2TB avec environ 512GB de données dessus. Le système d'exploitation démarre toujours après cela, les parties perdues semblent donc se trouver dans les données utilisateur ou les conteneurs docker.

Voici quelques détails supplémentaires sur le système affecté :

$ 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

Mise à jour :

Et quelques détails supplémentaires sur la configuration de l'hôte :

• en utilisant Hyper-V Server 2016
• le disque est basé sur un fichier de disque virtuel (par opposition à un disque physique)
• le disque est configuré pour être dynamique (c.-à-d. en croissance)
• il y a plusieurs snapshots/points de restauration sur la VM. Je ne suis pas sûr que cela fasse passer l'image disque de dynamique à différentielle ( ?).