Вот немного информации для размышления:

Подскажите какую ФС использовать под нагруженный mysql сервер (комментарий)

Если оставить ext4, есть ли смысл изменить extent на пример с 4 на 64?

Не знаю. Но вот что точно сильно снижает нагрузку на ФС, так это монтирование с параметром типа commit=600. Иначе на высокой нагрузки половина всего дискового IO переходит в непрерывную запись журнала.

raw part

А что скажете насчет raw partion?

Если база небольшая - то проще оттюнить мускуль, чтобы она вся в память укладывалась.

База 20 гигов

По идее оно позволяет устранить весь оверхед ФС. Но тогда с бэкапами сложность будет, станадартные методы для бэкапов типа innobackupex, xtrabackup, LLVM/ZFS снэпшоты не будут работать. Для базы в 20Г mysqldump особо не попользуешь. Поэтому в таком случае либо придётся жить без бэкапов, либо реплицировать базу на другой сервер (как вариант на другой mysql-server на этой-же машине, у которого база данных на другом разделе) и делать бэкапы уже оттуда.

Мы 200-гиговые в память укладываем :) Если действительно _настолько_ нужна производительность, то ИМХО побольше памяти - самое верное решение.

LVM-снапшоты как раз можно делать. А заодно можно будет расширить базу без шаманства с fdisk. Собственно, зачем делать raw partition без LVM?

Только LVM-снапшот предназначен исключительно для быстрых бэкапов, оставлять его живым надолго — плохая идея.

Нагрузка на сервер не большая. В среднем 2 запроса в 10 секунд.

Вопрос простой. Имеет ли в данном случае смысл переходить на xfs

если я правильно понял ТЗ, то время будет определяться исключительно скоростью позиционирования. Профита от ФС не будет, но вероятно будет ОГРОМНЫЙ профит от SSD (если запросы не закешировать. Иначе - купи памяти).

Мы 200-гиговые в память укладываем :) Если действительно _настолько_ нужна производительность, то ИМХО побольше памяти - самое верное решение.

согласен. Вопрос только в $$$...

да,про LVM это я не подумал.