Отключение журналирования ext4

Имеется сервер с Red Hat 6.9 в ЦОД, на котором крутится БД MySQL. Периодически начались проблемы с постоянным процессом JBD2/dm-2-8 , который отжирал весь IOwait (значения были под сотку).

В результате изучения и поиска информации по данному вопросу выявил следующее:

Сам по себе процесс записи в журнал не должен вызывать опасений – это нормально, что он пишет. Другой вопрос, что его вызывает так часто и почему высокий IOwait…

Так как в движке InnoDB работающего MySQL есть своё журналирование, то в системе его можно просто отключить без особых опасений, т.к. сервер в ЦОДе, и в случае сбоя ОС не должна аварийно завершить свою работу. Более подробно о нюансах отключения можно погуглить.

Теперь подбираемся к вопросу о непосредственном отключении журналирования. Рассмотрим основные опции, которые дадут нам также производительность:

data={ordered|journal|writeback}
{в журнал пишутся только мета-данные, данные полностью журналируются, журнал не ведётся}

commit=5 {интервал между sync, по дефолту 5, можно увеличить)

barrier | nobarrier {барьеры для упорядочивания запросов записи; можно отключить для прироста производительности}

Теперь, когда разобрались с основной теорией, можно приступить к практике:

Проверяем, что БД на отдельном разделе (не на системном):

df -h

Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup-lv_root
                       45G   11G   32G  26% /
tmpfs                 7.8G     0  7.8G   0% /dev/shm
/dev/sda1             477M   97M  355M  22% /boot
/dev/mapper/vg01-lv01
                      689G   55G  600G   9% /u01

Нас интересует /dev/mapper/vg01-lv01 и раздел /u01

Так как используется LVM, проверяем, что в VG только нужный нам диск:

pvscan

File descriptor 63 (pipe:[575263301]) leaked on pvscan invocation. Parent PID 18901: bash
  PV /dev/sdb1   VG vg01            lvm2 [700.00 GiB / 0    free]
  PV /dev/sda2   VG VolGroup        lvm2 [24.51 GiB / 0    free]
  PV /dev/sda3   VG VolGroup        lvm2 [25.00 GiB / 0    free]
  Total: 3 [749.50 GiB] / in use: 3 [749.50 GiB] / in no VG: 0 [0   ]

Как видно из выхлопа выше, в VG vg01 только один диск sdb1.

Останавливаем сервис MySQL и проверяем, что раздел больше никем не используется:

lsof | grep /u01

Если есть процессы, останавливаем их или kill -9

Теперь отмонтируем раздел (принудительно лучше не использовать):

umount /dev/mapper/vg01-lv01

Меняем тип журнала:

tune2fs -o journal_data_writeback /dev/mapper/vg01-lv01
tune2fs -O ^has_journal /dev/mapper/vg01-lv01

И обязательно запускаем проверку:

e2fsck -f /dev/mapper/vg01-lv01

Если пишет:

e2fsck 1.41.12 (17-May-2010)
/dev/mapper/vg01-lv01 is in use.
e2fsck: Cannot continue, aborting.

То смотреть в сторону lsof, что\кто занимает нужный раздел или так:

fuser -mv /dev/mapper/vg01-lv01

После того, как всё успешно прошло, нужно подмонтировать обратно с использованием нужных опций (я использовал только без барьеров):

mount -o nobarrier /dev/mapper/vg01-lv01 /u01