Потеря данных файловой системы EXT4 под управлением Debian 9 под KVM

Я пытаюсь настроить виртуализацию KVM на хосте CentOS 7.6.1810. Это машина с процессором Xeon E-2176G и двойным SSD-накопителем на 1 ТБ. SSD настроены как программный рейд.

Personalities : [raid1]
md126 : active raid1 sdb3[0] sda3[1]
      828441920 blocks super 1.2 [2/2] [UU]
      bitmap: 0/7 pages [0KB], 65536KB chunk

md127 : active raid1 sdb1[1] sda1[0]
      104856576 blocks super 1.2 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

SSD имеет загрузочный / корневой раздел и раздел подкачки, дополнительное пространство - это том LVM, созданный поверх тома raid для хранения виртуальных машин.

Вывод Fdisk:

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048   209848319   104923136   fd  Linux raid autodetect
/dev/sda2       209848320   218236927     4194304   82  Linux swap / Solaris
/dev/sda3       218236928  1875385007   828574040   fd  Linux raid autodetect

вывод vgdisplay:

 --- Volume group ---
  VG Name               vps
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  95
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                0
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               790.00 GiB
  PE Size               128.00 MiB
  Total PE              6320
  Alloc PE / Size       0 / 0
  Free  PE / Size       6320 / 790.00 GiB
  VG UUID               4jp2up-3ZDd-5zVb-2ZvC-SvC5-qwte-iXmSTt

Я использую SolusVM для развертывания шаблонов KVM, которые я создаю сам с помощью ISO-образа сетевой установки от Debian. Кажется, что все идет хорошо, но по мере загрузки машины и увеличения нагрузки ввода-вывода файловая система повреждается.

Я проверяю это, делая:

dd if=/dev/zero of=/tmp/test1.img bs=1G count=1 oflag=dsync

Затем команда прерывается, и файл журнала / dmesg показывает это.

[   77.921283] EXT4-fs error (device vda1): ext4_validate_block_bitmap:386: comm kworker/u2:1: bg 11: bad block bitmap checksum
[   77.968478] EXT4-fs (vda1): Delayed block allocation failed for inode 524302 at logical offset 165888 with max blocks 2048 with error 74
[   77.968573] EXT4-fs (vda1): This should not happen!! Data will be lost

[   77.970041] EXT4-fs error (device vda1): ext4_validate_block_bitmap:386: comm kworker/u2:1: bg 12: bad block bitmap checksum
[   77.971194] EXT4-fs error (device vda1): ext4_validate_block_bitmap:386: comm kworker/u2:1: bg 13: bad block bitmap checksum
[   77.972094] EXT4-fs error (device vda1): ext4_validate_block_bitmap:386: comm kworker/u2:1: bg 14: bad block bitmap checksum
[   78.342607] EXT4-fs error (device vda1): ext4_validate_block_bitmap:386: comm dd: bg 18: bad block bitmap checksum
[   78.490468] EXT4-fs (vda1): Delayed block allocation failed for inode 524302 at logical offset 231424 with max blocks 2048 with error 74
[   78.490563] EXT4-fs (vda1): This should not happen!! Data will be lost

Однако обычно вы думаете об аппаратном сбое:

• У меня есть 3 похожих хоста, все новое оборудование, с одной и той же проблемой.
• Только Debian 9 имеет проблему, CentOS в качестве гостевой виртуальной машины на EXT4 в порядке.
• Переключение Debian 9 на EXT3 вместо EXT4 решает проблему.
• Это происходит только при большой нагрузке ввода-вывода.

Я предпочитаю иметь EXT4. Есть идеи, что могло вызвать это? Я обв. используя последнюю версию Debian 9.9 с ядром:

Linux debian9 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u3 (2019-06-16) x86_64 GNU/Linux

Я работаю над этим уже 5 дней, но не могу найти решение. Я только нашел это:

https://access.redhat.com/articles/41313

Но я не уверен, что он описывает мою проблему, однако вариант 3 кажется мне обходным решением. Мои диски все же подписаны, и я решил. не используйте AIO = native.

Надеюсь, у кого-то есть ключ к разгадке!