Откатился с ядра 3.10.0-693.21.1.el7.x86_64 обратно на 3.10.0-514.26.2.el7.x86_64, проблема осталась. Пробовал поставить 4.4.120-1.el7.elrepo.x86_64, проблема также сохраняется.

Откатил LVM вместе с зависимостями от 2.02.171-8 к 2.02.166-1, проблема также сохранилась.

Мягко говоря, я в замешательстве.

Обновление от 13 марта: проблему для себя решил.

Я произвел чистую установку CentOS 7.4 со всеми актуальными пакетами, на ней проблему не удалось воспроизвести. Сравнил конфигурацию хранилища LVM из каталога /etc/lvm/backup, откуда выяснил, что на всех серверах metadata_format стоит в 1, а на свежей установке у хранилища стоит 2.

Что удалось выяснить - если система была обновлена с первых версий 7 ветки (точно не помню, возможно 7.1 или 7.2 изначально была установлена), то при подключении кеширования с помощью команды lvcreate без явного указания cachemetadataformat (по умолчанию стоит auto), почему-то ставилась 1 версия. А в новой установке при тех же условиях ставилась 2 версия.

Сама проблема воспроизводилась следующим образом - режим кешировния writeback, cachemetadataformat в 1. При записи на такое хранилище, процесс вел себя достаточно странно: помимо записываемых данных (которые по логике должны попадать в кеш и на диск), система производила чтение каких-то данных с HDD (в значительно больших объемах, чем велась запись), эти данные писались в кеш на SSD, а после завершения записи этот объем данных записывался обратно на HDD. Это очень хорошо видно в связке использования fio + iostat, виртуальные машины здесь не причем, проблема воспроизводится и без них.

Решение простое: отключаем кеширование и явно указываем версию мета-данных. Ниже пример команд, может кому-то пригодятся (переменные замените под себя):

lvconvert --uncache ${VG_NAME}/${LV_NAME}
lvcreate --type cache --cachemetadataformat 2 --cachemode writeback -L${SIZE}G -n ${LV_NAME}_cache ${VG_NAME}/${LV_NAME} /dev/${SSD}