XFS - высокопроизводительная 64-битная журналируемая файловая система, созданная компанией Silicon Graphics, поддержка которой включена в ядро Linux начиная с версии 2.4.25. XFS активно продвигается в мире Linux, и, например, некоторые дистрибутивы, такие как RedHat 7, CentOS 7 и Oracle Enterprise Linux 7 используют её по умолчанию.
У одного заказчика на одном сервере закончилось место на корневой файловой системе. Анализ занятого пространства временными файлами и журналами показал, что проблему надо искать где-то еще. Команда df -h /
говорила, что занято 18G из 18G и свободно около 20K, но вывод команды du -h /
показал, что занято около 5.5G. В традиционных файловых системах на unix-like ОС такое поведение может быть вызвано двумя причинами:
-
Повреждённая файловая система. Для исправления необходима перезагрузка для проверки консистентности файловой системы;
-
Были удалены файлы, открытые каким-то процессом. Не зная специфики используемого на узле ПО и выполненных ранее действий самым простым способом исправления также является перезагрузка - ОС высвободит место после завершения процессов.
Как не сложно заметить, для простого устранения обеих возможных причин необходима перезагрузка, и, соответственно, было принято решение о её выполнении на узле. Для того, чтобы в RedHat-подобных (и не только) дистрибутивах выполнить проверку файловых систем при перезагрузке можно создать в корневом каталоге файл с именем /forcefsck
или воспользоваться параметрами сервиса systemd-fsck.
После создания файла /forcefsck
и перезагрузки системы в /var/log/messages были найдены записи:
Dec XX 11:26:44 hostname systemd: Starting File System Check on /dev/mapper/centos-root...
Dec XX 11:26:44 hostname systemd-fsck: /sbin/fsck.xfs: XFS file system.
Dec XX 11:26:44 hostname systemd: Started File System Check on /dev/mapper/centos-root.
Из чего было сделано предположение, что файловая система была проверена. Но свободное место так и не появилось. Внезапно выяснилось, что XFS на столько Хорошая Файловая Система, что она считает, что она вся такая журналируемая и проверка консистентности при загрузке ей не нужна, а /sbin/fsck.xfs
представляет собой гениальный скрипт:
#!/bin/sh -f
#
# Copyright (c) 2006 Silicon Graphics, Inc. All Rights Reserved.
#
AUTO=false
while getopts ":aApy" c
do
case $c in
a|A|p|y) AUTO=true;;
esac
done
eval DEV=\${$#}
if [ ! -e $DEV ]; then
echo "$0: $DEV does not exist"
exit 8
fi
if $AUTO; then
echo "$0: XFS file system."
else
echo "If you wish to check the consistency of an XFS filesystem or"
echo "repair a damaged filesystem, see xfs_repair(8)."
fi
exit 0
И сообщение XFS file system
означало, что на самом деле никаких проверок не выполнялось, и надо запускать xfs_repair
руками. Выполнение проверки файловой системы на загруженной системе ожидаемо невозможно:
xfs_repair: /dev/mapper/centos-root contains a mounted filesystem
xfs_repair: /dev/mapper/centos-root contains a mounted and writable filesystem
fatal error -- couldn't initialize XFS library
Но и перезагрузив систему в single user и перемонтировав корневую файловую систему в режиме только чтение получаем сообщение:
xfs_repair: /dev/mapper/centos-root contains a mounted filesystem
Unmount or use the dangerous (-d) option to repair a read-only mounted filesystem
fatal error -- couldn't initialize XFS library
И только выполнив команду xfs_repair -d /dev/mapper/centos-root
XFS наконец-то проверяет консистентность файловой системы, находит какое-то количество потерянных файлов, помещает их в lost+found
и просит срочно перезагрузиться. После перезагрузки и очистки lost+found
свободное место наконец-то появляется.
При этом стоит отметить, что проблемы с потерей файлов на XFS при некорректном завершении работы ОС - не самая редкая проблема. И почему после такого завершения не выполняется полноценная проверка консистентности файловой не очень понятно.