Hetzner и I/O проблемы на Ext4

Сегодня мой проверяльщик серверов сообщил, что на одном из них появились проблемы. После логина, я увидел, что файловая система стала read-only. На VPS у меня такое бывало, спасала перезагрузка. Однако после перезагрузки я увидел очередное сообщение что система опять находится в режиме только-чтение..

Так же система мне сообщила следующее:

[5443.816119] ata1: lost interrupt (Status 0x50)
[5445.068671] end_request: I/O error, dev sda, sector 85250544
[5445.069145] Aborting journal on device sda3-8
[5445.069627] Ext4-fs error (device sda3) in ext4_da_write_end: IO failure
[5445.070117] Ext4-fs error (device sda3) in ext4_da_writepages: IO failure
[5446.088868] Ext4-fs error (device sda3): ext4_journal_start_sb: Detected aborted
journal
[5446.089278] Ext4-fs error (sda3): Remounting filesystem read-only
[5447.000465] Ext4-fs error (sda3): ext4_da_writepages: jdb2_start: 48 pages, inno
4325800; err -30

Насколько я понял, это была проблема с винтами, поэтому, я написал в тех. поддержку Hetzner-а, с просьбой помочь. Разумеется, я приложил эти логи, а так же скриншот, с более полным выводом этой инфы.

Ошибки I/O на VPS от Hetzner

Через пару часов, мне написали следующее:

Dear Client,Are you using the ext4 filesystem? If you are not sure you can check by typing
"mount | grep ext4".If you are using ext4 then the failure appears due to a short IO wait time in the
standard configuration of ext4. This causes the file system to automatically
switch into read-only mode.

To solve this issue please stop your virtual server and boot it into the Rescue
System to make a file system check. If the command "mount | grep ext4" for example
recognizes an ext4 filesystem at /dev/sda2, please perform the command
"fsck /dev/sda2"

After checking the file system you can boot the server normally into your standard OS.

If you change the timout for your system, you can prevent this failure from
happening again. To do that you can increase the latency via the command:
echo 120 > /sys/block/sda/device/timeout

This setting only stays until your next reboot. There are methods, depending on
your OS, to making this permanent.
If you are using Debian/Ubuntu for example, you can write this command in
/etc/rc.local.

Best Regards

Вкратце тут говорится, что подобное случается, т.к. по-умолчанию у Ext4 маленький таймаут I/O и советуют его увеличить до 120. Разумеется, я последовал совету, и увеличил его. Так же перед этим посмотрел значение по-умолчанию, оно равнялось 30.

После изменения значения, я перезагрузился, сделал REPAIR TABLE для баз данных и все заработало, в обычном режиме.

Не берусь рассуждать, про необходимость дополнительной конфигурации файловой системы, а так же их выбора, однако, надеюсь на то, что эта заметка, сэкономит время тем, кто столкнется с подобной проблемой.

А Hetzner-ам спасибо 🙂