Сыграем в линуксойд-бинго?
Вещи которые следует ненавидеть каждому настоящему линуксойду.
Показать полностью
1
raidshadowlegend
Обещаю никогда не пихать в свои посты рекламу своего телеграм-канала. Потому что у меня его нет)
10К
рейтинг
18 подписчиков
6 подписок
35 постов
24 в горячем
Куда могло исчезнуть дисковое пространство? (5/5)
Подытожим этот короткий цикл последним случаем.
Файловая система только для чтения
Последний из рассматриваемых кейсов может произойти из-за проблем с самим жёстким диском:
Мы не можем создать новый файл, хотя явно видно, что дисковое пространство у нас ещё есть. Посмотрим в каком режиме смонтирована файловая система:
Вывод mount даёт нам подсказку, что наша rootfs смонтирована только для чтения (ro).
Теперь имеет смысл приступить к чтению системных логов, чтобы лучше понять что именно произошло:
В логах видно, что ядро перевело файловую систему в режим read-only из-за - sysrq: Emergency Remount R/O.
Объяснений произошедшему может быть достаточно много. Тут сложно вывести какую-то общую рекомендацию для решения. Что нужно будет сделать наверняка: просмотреть сообщения dmesg, более детально логи системного журнала, сделать SMART тест жесткого диска.
Заключение
Когда ядро сталкивается с проблемами в работе файловых систем, оно ведёт себя в соответствии с аргументом error= команды mount. Этот аргумент может принимать следующие параметры:
errors=continue - игнорирует ошибки, однако помечает файловую систему как некорректную, после этого монтирование продолжается.
errors=remount-ro - перемонтирует файловую систему в режим "только для чтения".
errors=panic - аварийно завершает процесс монтирования и блокирует работу системы.
Нужное поведение при монтировании можно настроить в /etc/fstab.
Нельзя забывать, что подобная ошибка сообщает о вероятной проблеме с железом, поэтому в случае возникновения такой ошибки в первую очередь необходимо будет проверить корректность состояния физического устройства.
Показать полностью
2
Куда могло исчезнуть дисковое пространство? (4/5)
Inodes
Продолжая тему исследования того, куда могло исчезнуть место на диске, рассмотрим новую задачу.
Сервер перестал отвечать. Смотрим по логам, что произошло:
Ок, делаем стандартные проверки для подобного сценария:
Ну, у нас определённо есть свободное пространство, но что-то всё равно пошло не так. Давайте попробуем посмотреть ещё кое-что:
-x tmpfs -x squashfs из первой части, тут также может быть вполне уместно применить
Сервер использовал все доступные inode.
Попробуем найти директорию, с наибольшим количеством использованых inode:
Чтож. Довольно предсказуемо. Теперь провернём небольшой трюк:
Мы смонтировали tmpfs в /tmp. Оно конечно само по себе может вызвать проблемы, но мы тут и так уже посреди инцидента, так что двигаемся дальше:
Почистим эту директорию:
Ладно. Пойдём другим путём:
Решение на perl не единственное, но одно из самых быстрых. С другими возможными вариантами решения можно, например, ознакомиться здесь.
Заключение
количество индексных дескрипторов в файловой системе определяется во время создания. Несмотря на то, что их число достаточно велико, тем не менее они могут быть исчерпаны.
такой тип инцидентов крайне редкий. В основном подобное может случиться в системах, где создаётся множество мелких файлов. Например почтовый сервер, в котором письма хранятся в файлах, накрыла волна спама.
Показать полностью
7
Всякий раз когда пользуешься бесплатным VPN
Хуже всего, что иногда, независимо от правильности ответа, капча зацикливается, и ты бесконечно пытаешься определить "не мотоцикл ли этот диван?"
Показать полностью
1
Куда могло исчезнуть дисковое пространство? (3/5)
Новый день и новый алерт от системы мониторинга.
Смотрим логи системы:
Так, опять закончилось место. Что на этот раз?
Любопытно. Всего у нас 4.9 гигов. 4.6 из них использовано. Но занятыми почему-то считается все 100% дискового пространства. Куда делось 300 метров?
В поисках ответа, рассмотрим более детально файловую систему с помощью tune2fs:
Так, у нас тут есть какие-то зарезервированные блоки. Для того, чтобы прояснить что за блоки нам встретились, вновь обратимся к Linux API исчерпывающее руководство от Майкла Керриска, стр. 312 (просто удобно делать все отсылки к одной книге, хотя в Advanced Programming in the Unix Environment про это тоже можно почитать)
Многие «родные» файловые системы UNIX и Linux поддерживают представление о резервировании некоторой части блоков файловой системы для суперпользователя на тот случай, когда файловая система становится заполненной. Суперпользователь по-прежнему может войти в систему и принять меры по устранению данной проблемы. Если в файловой системе есть зарезервированные блоки, то разность значений полей f_bfгее и f_bavail в структуре statvfs сообщит нам, сколько блоков зарезервировано.
То есть место было зарезервировано для того, чтобы поддержать работу системы на тот случай, если свободного места на диске вообще не останется.
Теперь давайте слегка изменим настройки файловой системы, чтобы у нас появился небольшой запас пространства, и немного времени на решение проблемы:
Отлично, теперь есть немного места, и можно более-менее в штатном режиме начать поиск решения.
Заключение
многие файловые системы резервируют дисковое пространство для суперпользователя. Это механизм защиты, позволяющий поддерживать работу системы (и разрешать администратору вход в систему), когда на диске не осталось свободного места.
объем зарезервированного пространства можно изменить. Это сделает некоторое количество блоков пригодными для использования и поможет вам выиграть немного времени. Но будьте осторожны, вам все равно нужно проанализировать, что происходит, и исправить это должным образом.
на больших файловых системах (>50–100 ГБ) резервирование 5% является излишним. Так что возможно вы захотите проверить свою файловую систему и уменьшить количество зарезервированных блоков (однако к любому тюнингу и оптимизации нужно подходить с умом и без фанатизма).
Показать полностью
1