Наш сайт крутится на виртуальном сервере KVM. И вроде все шло хорошо, пока вдруг файловая система ext4, которая стояла на единственном разделе вдруг перемонтировалась в read only mode. По-глупости, забыв проверить /etc/fstab на значение последней циферки сервер был перезагружен, т.к. перемонтирование в rw было невозможным. После еще одной перезагрузки файловая система похерилась. А циферка-то была 0 :)
Восстановив нужные файлы после fsck и манипуляций с find /lost+found решено было разбить виртуальный жесткий на два раздела: один с reiserfs, а второй со всё той же ext4.
После непродолжительного времени стабильной работы, ext4 благополучно навернулась опять и снова. Но на этот раз проверки в fstab были включены и данные остались невредимыми. Но сам факт нестабильной работы файловой системы заставил задуматься над решением проблемы.
Проблема, если Google нашел правильно, заключается в баге виртуальной машинки, правда баг помечен как решенный, но в дикой природе все еще встречается. Ядро самое свежее, доступное из стандартных дебиановских реп.
Решение проблемы заключается и изменении опций монтирования раздела с ext4. Вот как выглядит строчка /etc/fstab для многострадального раздела.
# file system mount point type options dump pass
/dev/sda6 /home ext4 defaults,noatime,nodiratime,errors=remount-ro,barrier=0 0 1
Единственное, на что тут стоит обратить внимание — так это на отключенные барьеры (barrier=0). Исходя из man, барьеры нужны для сохранения данных при внезапном отключении электричества.
В датацентре внезапное отключение электричества всех каналов так же вероятно, как то, что этот сайт посетит министр финансов Китая, поэтому отключение этой опции не только спасает нас от бага, но и ускоряет производительность файловой системы.
Немного информации о барьерах на русском. Ссылка