Очень странная ошибка повреждения диска
У меня есть сервер, на котором я удалил большой файл. Назовем его ~ / tempfile.txt . Каким-то образом удаление не сработало должным образом, и диск был поврежден - это означает, что du -hs * не показывает, что этот файл существует. Но df -h показывает, что корневой раздел заполнен.
Оказывается, это известная проблема, которая может произойти из-за того, что к "удаленному" файлу обращается запущенный процесс. Ответ stackoverflow предлагал запустить lsof + L1 , чтобы получить список таких файлов. Что ж, при его запуске появляется следующая запись:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME
none 2241 root txt REG 0,5 8560 0 52453 / (deleted)
Пара странностей:
- «Имя» должно быть «~ / tempfile.txt», но это не так.
- Номер inode - 52453 указывает на какой-то другой файл:
/usr/src/linux-azure-headers-5.0.0-1025/include/uapi/video/sisfb.h. - Процесс с PID 2241 не существует.
Стандартная процедура - убить PID, обращающийся к этому файлу, но, что ж, такого процесса нет.
Я попытался перезагрузиться, но это не вернуло свободное пространство (что должно быть, если процесс обращается к файлу ). Вместо этого выполнение lsof + L1 снова дало запись, но на этот раз номер inode и pid были другими, но поле «Имя» было таким же ( / ).
Я подумал о запуске fsck. Сначала запустил его непосредственно в режиме пробного прогона, используя fsck.ext4 -nvf / dev / sda1 , и в выводе было сказано, что есть некоторые проблемы: «Количество свободных блоков неверно, количество свободных inodes неверно, различия в битовых картах блоков» и т. Итак, я подумал: позвольте мне перезагрузить систему и смонтировать корневой раздел в режиме только для чтения, и запустить на нем fsck.
Хорошо. fsck.ext4 -nvf / dev / sda1 показал, что все в порядке! Итак, я попробовал запустить lsof + L1 , и сюрприз, сюрприз. Никаких файлов-призраков! Свободно ли теперь место на диске? df -h - все еще используется 100% диск.
Я попытался перезагрузить с rw-монтированием корневого раздела, и fsck & lsof + L1 пожаловались снова.
Это продолжает происходить детерминированно - режим только для чтения не показывает ошибок, тогда как монтирование чтения-записи показывает ошибки диска.
Я понятия не имею, что происходит. У кого-нибудь есть разумное предположение, в чем может быть проблема?
У меня есть резервная копия данных, поэтому я могу просто запустить другой сервер с данными, но это очень странно, и я хотел бы понять, что происходит.
Создайте образ диска, чтобы иметь копию для работы.
Просмотрите использование диска в верхней части дерева, чтобы убедиться, где используется большая часть хранилища. (Или нет, если дентри не может перечислить проблемный файл.) ncdu - это программа, которая визуализирует использование пространства дерева.
fsck блочное устройство во время чтения, записи и размонтирования (и сохранение вывода ). Это звучит как rootfs, и в этом случае рассмотрите возможность подключения диска к другому экземпляру и fsck там. В противном случае настройте среду ранней загрузки так, чтобы она всегда была fsck, а затем перезагрузитесь. Как это сделать, зависит от дистрибутива, например systemd выполняет ранний fsck иначе, чем предыдущие сценарии инициализации. В любом случае, проверьте такие вещи, как потерянные inodes, которые могут получить ссылку в lost + found .
lsof имеет ограниченное использование, если файл не открыт в данный момент. Возможно, вы видите несвязанные открытые несвязанные файлы.
При наличии резервной копии восстановление или новый экземпляр - это быстрое восстановление. Насколько далеко вы хотите исследовать, зависит от вашего любопытства и от того, может ли эта проблема возникнуть снова.