Особенности discard/trim на старых версиях ядер : Linux

Вчера столкнулся с базой (сервис работает 24х7, хех), работала, работала, оп-п, исчезла. Хорошо, что не переключились на standby, через некоторое время исчез и он, причем, машинка была послабее и исчез он еще на большее время.

Начал разбираться - в iostat avgrq_sz больше 200к, при этом количество операций чтения и записи упало до 1 в секунду.

База жива, но ничего не пишется на диск.

Даже простой sync не проходит. Версия ядра 3.10



К счастью, вспомнил, что у меня творилось с trim около 10 лет назад.

Посмотрел
/dev/mapper/mpathi1 on /oradata type ext4 (rw,relatime,discard,stripe=1024,data=ordered)
судя по всему - оно самое...

В итоге, резюмирую, если ядро старое и не умеет асинхронный trim, то лучше опции монтирования проверить, чтобы trim не работал постоянно, всяким discard/trim (опции менялись на разных версиях ядра) не место на сервере.

Обратите внимание, что суть проблемы в сошедшихся звездах, старое ядро и на некоторых устройствах почему-то trim не видит то, что надо очистить, поэтому работает полностью по диску. В итоге получили простой сервиса более часа, после чего база через некоторое время грохнулась из-за таймаутов каких-то процессов записи. То есть, общая рекомендация, если так серьезно залипли, то базу после отвисания лучше перезапустить.