Linux df h доступное место некорректно показывается

du и df показывают разное, куда делось место на диске?

Объясните пожалуйста, как такое может быть:
Партиция var занимает по показаниям du полтора гигабайта,
однако df говорит что она заполнена на 83 процента и занимает 8 гигов!

itdevelopment / # du -sm /var
1652 /var

itdevelopment / # df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 9775248 8104632 1670616 83% /var
.
itdevelopment / #

Re: du и df показывают разное, куда делось место на диске?

lsof | grep inode | grep /var
lsof | grep deleted | grep /var

Re: du и df показывают разное, куда делось место на диске?

имеет смысл загрузиться с сдрома и проверить fsck /dev/sda2 на предмет потерянных файлов

Но вполне возможно, что все в порядке.

df показывает размер в занятых кластерах, а du суммирует полезный размер файлов

в этой ветке есть, например, /var/cache с кучей мелких файлов, так что вполне возможна потеря места в неиспользуемых хвостах.

смотри du -sh /var/* а также find /var | wc -l и анализируй, где пропажа.

Re: du и df показывают разное, куда делось место на диске?

ну и ты ж не забывай что в юникс встроенн сборщик мусора:) Даже если файл удален и du его не видит, но если какой-то процесс продолжает держать его открытым, то файл будет продолжать занимать место и учитываться df.

Re: du и df показывают разное, куда делось место на диске?

> ну и ты ж не забывай что в юникс встроенн сборщик мусора:) Даже если файл удален и du его не видит, но если какой-то процесс продолжает держать его открытым, то файл будет продолжать занимать место и учитываться df.

Проще говоря, если ты удалил логи, то надо перезапустить сислог командой:

Источник

Почему df -h показывает другую информацию, чем fdisk -l

Я пытаюсь понять разницу между выводом fdisk -l а также df -h , Насколько я понимаю, fdisk показывает размер раздела, и df показывает размер файловой системы.

Моя проблема в том, что у меня есть несоответствие между размером раздела и размером файловой системы.

из fdisk -l мы видим, что размер раздела установлен на /dev/sda5/ 797,2 ГБ.

из df мы видим, что размер файловой системы составляет 784 ГБ.

У меня всего 744G свободного места. Это нормально, потому что 5% файловой системы (784) зарезервированы.

Где пропавшие 13ГиБ?

редактировать:

Я использовал pxe preseed для создания разделов:

1 ответ

У вас всегда будет разница в выводе

В моем случае у меня разница составляет около 1,5 ГБ, что составляет около 1,3 % от размера раздела.

Для определения реального размера файловой системы вы можете использовать

Мы видим, что файловая система и раздел имеют одинаковый размер:

Так df не отображает размер файловой системы, он отображает размер, который доступен для пользователей. Некоторое пространство в файловой системе зарезервировано для файловой системы (например, журнала) и недоступно для пользователей, поэтому не отображается.

Когда я рассчитываю с 1,3 %, это даст разницу в 10,4 ГБ для раздела 800 ГБ, это почти столько же, сколько не хватает места, оно не потеряно в пространстве, это накладные расходы на файловую систему.

Примечание: я вырезал вывод команды в моих примерах в соответствующие строки, чтобы сохранить порядок.

Пространство зарезервировано для root:

Зарезервированное пространство для root доступно, но только для пользователя root. df отображает это количество пространства, как используется, запутанная вещь, что df отображает те же значения, когда вы работаете df как root или как другой пользователь. В конфигурации по умолчанию 5% пространства будет зарезервировано для root (причины см. Здесь). Можно уменьшить этот объем пространства, что, на мой взгляд, имеет смысл для вашего довольно большого раздела, поэтому больше места будет доступно для других пользователей. Не стесняйтесь уменьшить пространство, отведенное для root, до одного или двух процентов с

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

Источник

df и свободное место

Есть слабая машинка для эспериментов, имеющая маленький винт — 3гб
В ходе сборки очередной программы кончилось место, решил почистить не нужное, но места «не прибавилось».
Загрузился с кнопикса, проверил — лучше не стало:

Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda2 2488336 2422888 0 100% /
/dev/hda1 97570 13033 79499 15% /boot
none 128280 0 128280 0% /dev/shm

т.е полагаю свободно 2488336 — 2422888 = 65448 kb
Вроде так и есть: файл небольшой смог скопировать на hda2 — значит место есть, но почемуто df некорректно отображает в колонке «Available».
До заполнения диска отображал нормально.
Как вернуть правильное отображение df? Почему такое странное поведение?

Re: df и свободное место

Во-первых юзай df с опцией -h, чтобы отображение было в человеко-читаемом формате.

Re: df и свободное место

Re: df и свободное место

Корректно он все отображает. Часть мста резервируется под суперюзера. man tune2fs, ежели ext2/3.

Re: df и свободное место

читайте маны, они рулез. man tune2fs на предмет reserved blocks Ну и fsck неплохо прогнать, хотя вряд ли проблема в этом.

Re: df и свободное место

Все корректно! Просто в файловой системе делается запас, доступный только root. df похоже показывает свободное место без учета этого запаса. А вот на Фре недавно место кончилось — так df выдал занято 101% и свободно отрицательное число мегабайт!

Источник

df в linux не показывает правильное свободное место после удаления файла

У меня есть файловые серверы, которые используются для хранения файлов. Файлы могут находиться там в течение недели или года. К сожалению, когда я удаляю файлы с сервера, df команда не отражает освободившееся пространство. В итоге сервер заполняется ( df показывает 99%), и мой сценарий больше не отправляет туда файлы, за исключением того, что там может быть несколько десятков ГБ свободного места.

Я получил noatime флаг на смонтированных разделах, если это что-то меняет.

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

чтобы выяснить, какой процесс использует удаленный (несвязанный) файл.

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

Тем не менее, вы можете восстановить пространство, не убивая процессы. Все, что вам нужно сделать, это удалить дескрипторы файлов.

Сначала выполните lsof | grep удален, чтобы идентифицировать процесс, содержащий файл

«1» будет дескриптором файла. Теперь введите «> FD», чтобы освободить это пространство

Возможно, вам придется повторить операцию, если есть другие процессы, содержащие файл.

Одна возможность состоит в том, что удаленные файлы имеют больше ссылок в файловой системе. Если вы создали жесткие ссылки, несколько имен файлов будут указывать на одни и те же данные, и данные (фактическое содержимое) не будут помечены как свободные / пригодные для использования, пока все ссылки на них не будут удалены. Прежде чем удалять файлы, либо укажите их (запись с именем Links), либо выполните для них команду ls -l (это должен быть второй столбец).

Если выясняется, что на файлы есть ссылки в другом месте, я думаю, вам придется ls -i файл (ы), чтобы найти номер inode, а затем выполнить поиск с помощью -inum , чтобы найти другие ссылки на этот файл (возможно, вы также захотите использовать -mount, чтобы остаться в той же файловой системе).

Файл все еще заблокирован процессом, открывающим его. Чтобы освободить место, выполните следующие действия:

Запустите sudo lsof | grep deleted и посмотрите, какой процесс содержит файл. Пример результата:

Убить процесс с помощью sudo kill -9 . В приведенном выше примере PID составляет 1623.

Запустите, df чтобы проверить, освободилось ли место. Если он все еще заполнен, возможно, вам нужно подождать несколько секунд и проверить еще раз.

Если раздел настроен на резервирование определенной части дискового пространства только для использования root, df не будет включать это пространство как доступное.

Даже после освобождения места путем удаления файлов / каталогов, пользователь без полномочий root не сможет писать в определенный раздел.

Вы можете легко проверить, так ли это, попытавшись создать файл на устройстве как пользователь root и не пользователь root.

Кроме того, вы можете проверить конфигурацию файловой системы, запустив

и рассчитать фактический% самостоятельно.

Чтобы изменить% диска, зарезервированный для использования только в корне, выполните

Другие ответы верны: если вы удаляете файл, а пространство не освобождается, это обычно либо потому, что файл все еще остается открытым, либо на него есть другие жесткие ссылки.

Чтобы помочь в устранении неполадок, используйте инструмент, который сообщит вам, где место на диске расходуется: вы можете использовать, du чтобы получить представление о том, где место на диске . Еще лучше использовать графический инструмент, такой как xdiskusage (их много), чтобы выследить преступника. xdiskusage и друзья позволяют вам углубиться в самых больших космических свиней, чтобы найти, куда идет космос.

Таким образом, вы быстро найдете файлы, которые все еще занимают место из-за второй жесткой ссылки. Он также покажет пространство, занимаемое удаленными, но открытыми файлами (я считаю, что (разрешение запрещено), поскольку он не может прочитать имя файла).

Так как я знаю, что многие из вас делают это для redhat /var и gzip-файлов, ожидая сокращения FS, но вместо этого она увеличивается, просто убедитесь, что вы перезапускаете syslog службы. а также

покажу вам это в любом случае.

Еще один вариант: диск может быть заполнен из-за процесса, который постоянно создает данные: журналы, ядра и тому подобное. Возможно, что пространство на самом деле освобождается, но сразу же заполняется. Я действительно видел такой случай. df в этом случае просто не дает картину дыры. Используйте, du чтобы узнать больше.

Я использую EXT2, FSCK помог мне в этой ситуации. Попробуйте shudown -F сейчас, после некоторых перезапусков и fscks, я вижу половину используемого пространства.

Чтобы проверить, какие удаленные файлы заняли память, введите команду

Он покажет удаленные файлы, которые содержат память.

Затем убейте процесс с помощью pid или name

проверьте сейчас у вас будет такая же память

Если нет, введите команду ниже, чтобы увидеть, какой файл занимает память

укажите любой размер, который покажет, какие файлы занимают размер выше порогового, и удалите файл, в котором останется память

открыть терминал, попробуйте эту команду df -Th, затем используйте эту команду sudo du -h —max-deep = 1 / в этой команде вы найдете подробности использования диска, затем откроете, как пользователь root удалит файл (root-local-share-trash) и удали свой файл

Источник

Диск занят на 100% и не понятно чем, df и du показывают разные значения

Столкнулся сегодня с нестандартной ситуацией, когда на сервере исчезало место на диске, а я не мог понять кто его занимает. Хотя ситуация не такая уж нестандартная, но из-за ряда случайностей, она получилась в какой-то мере курьезной. Я по сути на ерундовую ошибку потратил много времени.

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

В данном случае сервер это виртуальная машина, у нее один диск и один корневой раздел, на котором все расположено. На диске ext4 поверх lvm. Задача увеличить свободное место в корневом разделе без перезагрузки сервера. С lvm все очень просто. Добавляем к виртуальной машине диск нужного размера и выполняем в консоли:

Иногда конструкция -l +100%FREE не срабатывает при увеличении раздела, хотя при создании все в порядке. Тогда можно указать добавляемый размер явно:

В моем примере есть системный диск sda, на котором расположен том vg00, а на нем логический раздел root. Мы расширяем том vg00 с помощью нового диска sdb, а затем расширяем логический раздел root до 100% свободного места тома.

После этого системный раздел будет увеличен сразу, перезагрузка не требуется. Можно не добавлять отдельный диск, а увеличить существующий через свойства диска в панели гипервизора. Тогда вам нужно будет на новом свободном месте на диске sda сделать новый раздел, например, sda2 и расширить том с его помощью. Как делать лучше, увеличивать диск или добавлять новый — не знаю, я и так, и так делаю. Тем не менее, считаю это плохой практикой, лучше сразу спланировать раздел диска и потом уже его не трогать. Данный способ это крайний случай, когда по-другому уже никак.

Проблема вроде как решена. Через пару дней ко мне обращается этот же разработчик и говорит, что места опять нет и он не понимает, кто его занимает. Тут я уже внимательно посмотрел на сервер. Посмотрел размер всех папок с помощью нехитрой конструкции, запущенной в консоли с корня диска:

Получим сразу в консоли размер всех директорий. У меня получилось так, что если сложить объем всех директорий, то получится занятыми где-то 6 Гб диска. А если выполнить команду

То видно, что корень занят на 100%, а его размер равен 20-ти Гб. Кто занял остальные 14 гигабайт места было не понятно.

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

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

Переходим к конкретике. Когда у вас сложилась ситуация, что не понятно, куда делось свободное место, которое ничем не занято, первым делом проверьте удаленные файлы, которые все еще открыты каким-то приложением:

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

А причина проблем со свободным место была вот в чем. Пару недель назад разработчик зашел на сервер и просто удалил лог ошибок nginx. И не перезапустил его. Он где-то неделю так проработал, а потом резко увеличил интенсивность записи в этот файл. Он постоянно рос, пока не занял все пространство раздела. После этого я увеличил раздел, и он снова плавно все занял.

Смысл в том, что nginx несколько дней писал в удаленный файл, который занимал место на диске. Если бы разработчик не трогал этот лог, то он бы ротировался раз в сутки и проблемы бы не было. А так он из системы был удален, но реально постоянно рос, его не было видно и он не обрабатывался с помощью logrotate.

В итоге через пару часов, когда я уже готовил подменный сервер, еще раз внимательно все проверил и обратил внимание на удаленные логи и место, которое они занимают. Вопрос решился простым перезапуском службы nginx. Он тут же отцепил свой лог файл и начал писать в новый. А старый реально удалился из системы и освободил место.

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

Можно оценить примерно, сколько стоит аккуратная работа. Если бы я просто перезагрузил сервер, то решил бы вопрос за 5 минут. Но пришлось действовать наверняка и тратить время. Когда-то это оправданно, когда-то нет. Лично я всегда перестраховываюсь и действую наверняка.

Источник