Куда делось место?
Куда-то пропало место. Есть винт на 53 гиг /dev/sda1
Команда раз: df -h
Т.е 93% места == 47 гиг занято.
Команда 2, смотрю детальнее:
Т.е. явно до 20 гиг занято.
Куда копать дальше?
Читать невозможно, либо пиши через userline, либо на пастебину залей.
В гноме есть утилитка, baobab называется.
Поправил текст, теперь читаемо.
чаще всего встречаются два варианта:
есть открытый файл, на который нет ссылки на ФС, соответственно du не может его посчитать, но и полностью удалить его нельзя т.к. какая-то программа держит его отрытым. проверять с помощью lsof | grep unlinked, или через /proc/
запись о свободном месте хранится в суперблоке, он может быть поврежден. прогони fsck.
начни с первого варианта.
Можно просто перезагрузиться и посмотреть, что выйдет
Команда lsof | grep unlinked ниего не показала
А вот после перезагрузки все сошлось 🙂 Спасибо.
Значит, val-amart попал в точку: какая-то зараза открыла здоровенный файл, но сразу сделала ему unlink. В результате du занятое место не находил, а df показывал под завязку забитый диск. Бывало у меня такое с переполняющимися логами, когда слишком жирный лог я удалил, а службу, его пишущую, не перезапустил. И получается: вроде как лога нет, а место он до сих пор занимает.
lsof | grep deleted
поэтому логи нужно чистить так: echo «» > /var/log/fat_log
Эта команда сделает unlink старому логу и создаст новый. Так что ничего не изменится.
в том-то и дело что нет, можешь проверить.
с чего это? как раз и обнулится. просто тут етсь тонкость — если пишущая туда прога запомнила метсо куда писала и потом делает по нему seek каждый раз — то появится дырявый файл со всеми вытекающими отсюда сюрпризами 🙂
подпишусь под мнением val-amart с уточнением Eddy_Em
tune2fs -l /dev/sda2 | grep -i «block count»
Источник
Куда девается свободное место?
Не могу обновиться, система пишет недостаточно соводно места
В чем загвоздка?
Если у тебя ext4, то у них есть inodes — блоки, куда пишется информация о файлах, их количество ограниченное и зависит от размера файловой системы.
Чем она больше, тем больше их.
Но это можно переопределить при создании файловой системы.
Блин, без сноса системы это пофиксить можно?
Изменять число Inodes после создания файловой системы нельзя.
Вообще, 15 Гб вполне нормальный размер. У вас по какой-то причине, скорее всего, на файловой системе создано много файлов.
Удалит их, подумайте где и когда вы могли создать большое количество мелких файлов.
Ну если не разберётесь — переустанавливайте на другую файловую систему, не ext3 / ext4, любая другая.
Не знаю в чем тут проблема. Можете, как вариант, запустить BleachBit. Пишу с Kali Linux Light
Я вручную вычистил /var/cache/apt/archves. Один раз помогло, но места не сильно прибавилось, может нужно было строго через apt-get clean. Где и как еще поискать мелочевку?
без сноса системы это пофиксить можно?
Встречал в интернете рецепты по трансформации ext3/ext4 в btrfs прямо на месте с помощью штатной btrfs-convert. Не знаю, работает ли это сейчас.
У btrfs нет лимита на иноды, как в ext4, так что может помочь.
без сноса системы это пофиксить можно?
Я читал недавно книгу: Р. Херцог и другие. «Каli Linux от разработчиков», изательство «Питер», 2018 год. В этой книге советуют использовать Kali с флешки.
Ок. Попробую пока этот варик
С нее и пользую
Вариант с флешкой — это тоже вариант на любителя. В моей практике у меня даже домашние CDR (DVDR) диски неавторизованно (несанкционированно) редактировали.
Увы прогой добился только такого результата
Повторяю, увеличить число inodes на уже созданной файловой системе невозможно.
Ты можешь только изменить число зарезервированных для root блоков, по умолчанию 5%.
Фигово. Ну а измениение числа root блоков, я так понял не на что не повлияет. С конвертацией фс могут возникнуть проблемы, флешка зашифрованна.
Уходит в след за детством по мере скачивания видеофильмов.
1. Получите базовое профильное образование по компьютерной специальности в хорошем университете.
3. Читайте книги по компьютерной специальности.
Достаточно калолинуксом перестать пользоваться, остальное обычному пользователю нафиг ненать.
Лол. Ncdu/filelight заюзай, недавние файлы find найдёт без проблем. Ну а вообще чё ты хотел, создай раздел с большим числом инод, если не хватает.
Да, а потом появляются вот такие для новичков. chroot
посоветую утилитку ncdu -NCurses Disk Usage. красиво и интерактивно в консольке можно эффективно порезать лишние файлики.
к сожалению с количеством файликов/нодов оне не работают, что есть жаль.
закончились иноды для ехт4 это «фсё». единственный выход без переформатирования и копирования содержимого тебе подсказали — конвертнуть в бтрфс. в бутере ограничений по инодам нет. конвертацция возможна без переформатирования. параллельно с ехт4 файловыми индексами создается бтрфс. после чего ехт4 удаляешь, все файлики даже с места не двинутся.
Я сначала тоже так подумал, только на флешку много не скачаешь
Источник
Куда то пропало место на жестком диске
Есть VPSка с диском 50 GB. Недавно заметил что оставшееся место — 6 GB. Всё бы ничего, но помимо обычных системных файлов дистрибутива, своих данных у меня на этой VPSке от силы гигов 10.
Я правильно понимаю что Avail показывает оставшееся место?
В корневом файле запускал проверку размера папок с сортировкой, чтобы самые толстые оказывались вверху:
lsof | grep deleted
интересный ты тип
или объяснить, что 1000 > 1?
Это всё? Маловато будет, там всего на 635Мб
скопировал всё что выдало
Перезапусти zabbix, mysql, apache
кто нибудь напишите болезному ещё раз про ncdu
Может еще и иксы на сервер накатить?
остается сделать reboot, fsck и всё вобщем-то
du -xmt 1G / | sort -n
Дурак ты, анон. Твой любимый ncdu просто не нужен.
А давно ncdu требует иксы? Может я что-то пропустил?
С тех пор как школоло не могут в du.
Ну ты еще топ вместо htop предложи юзать. Удобство важнее понтов.
У тебя может быть в каком-нибудь каталоге лежат файлы и поверх него смонтирована фс.
mkdir /mnt/testroot
mount —bind / /mnt/testroot
du -max —max-depth=1 /mnt/testroot | sort -n
В корневом файле запускал проверку размера папок с сортировкой
Что это ты запускал? Предлагаю du -hsx /* .
ps же. И понты тут не при чем. top иногда слишком дорого запускать.
Плюсую, пара тем уже была, где в конце концов так оно и оказалось.
У вас OpenVZ и simfs? Такое бывает, обращайтесь к хостеру.
top иногда слишком дорого запускать.
-b :Batch-mode operation
Starts top in ‘Batch’ mode, which could be useful for sending >output from top to other programs or to a file.
но куда тебе, недоумку, открыть man, не так ли?
Сначала сам в ман залезь, родной. 1G не заметить это совсем надо имбецилом быть.
От топа в батче пользы как от козла молока.
ты настолько тугой, что даже жалко. зачем нужно показывать суммарный размер /, и ещё пытаться его сортировать относительно самого себя?
ты не можешь связно ответить ни на один вопрос, только кукарекать выборкой «козла молока», «школоло», «не нужен». с человеком ли я имею дело
Если баш и настройки по-умолчанию, то не покажет файлы начинающиеся с точки, которые лежат в корне.
Проблема вот где:
Папка с логами весит 32 гигабайта, это вообще законно? Серверу месяца 4. Если для меня нет ничего важного в тех логах я могу полностью почистить всё из этой папки? или что то нужно оставить?
Тугой тут только ты. Нет чтобы просто уменьшить threshold и посмотреть, продолжаешь ударную газификацию.
файлы начинающиеся с точки, которые лежат в корне.
Держите извращенца. Конечно, не покажет — а они там есть?
как же ты раньше du запускал, что /var был ★★★★★ ( 21.07.14 22:45:19 )
Ты logrotate ставил?
Ну так чего ты хотел? Поставь, настрой, в логи ж день-деньской гадит кто ни попадя. Пыхокод с ошибками и варнингами в том числе, кстати.
папку log можно полностью всю почистить? или есть лог файлы которые нужны каким то службам для работы?
Ты сначала logrotate поставь, он всё пожмёт, потом будешь думать, надо чистить или не надо. Логи однородные и очень хорошо жмутся.
По-нормальному они не должны ничем использоваться, так что можно и удалять. Но на практике удаление файлов, в которые кто-то пишет, может аукнуться, так что службы предварительно лучше остановить, а после вообще ребут сделать.
Ничего не аукнется. Логи можешь спокойно удалять.
Если файл открыт каким-то процессом то при «удалении», он не удалится из фс, пока будет открыт (man unlink).
Максимум что ты потеряешь — логи от этого процесса.
Держите извращенца. Конечно, не покажет — а они там есть?
Они там могут быть. Мы же не знаем что там у ОПа. Может он cat /dev/zero > /.thereisnothing сделал.
Папка с логами весит 32 гигабайта, это вообще законно?
Это вообще по дефолту. Уровень информативности надо было настраивать, а не предьявы тут кидать.
Ну тогда он ССЗБ, о чём может быть речь? =)
Источник
Куда может «утекать» свободное место на диске?
Некоторое время назад у меня после старта ОС стало всплывать сообщение о том, что в корневой ФС осталось мало свободного места. Места становилось все меньше и меньше при том, что никаких новых пакетов я не за это время не устанавливал. Удалил кое-какие ненужные пакеты. Но через некоторое время свободное место опять сократилось. Сейчас вообще свободно 100К. И это при том, что в последнее время даже апдейты не ставил. Корень, var и home у меня на разных разделах. Поэтому ничего, кроме того, что я подцепил что-нибудь нехорошее из Инета, в голову не приходит. Но таки может дело не этом? Может это чудеса ext4, к примеру? Может что-то поломалось, и у нее журнал забивается чем-то. Что подскажите коллеги? Где бы что бы покопать?
логи,
кэш пакетной системы(той которая устанавливает программы)
неисправное шифрование или ещё какая школоло поделка от авторов убунты/или какого-то другого дурного дистрибутива eCryptfs съедает место?
О «du» никогда не слышал?
Поэтому ничего, кроме того, что я подцепил что-нибудь нехорошее из Инета, в голову не приходит.
Загрузись с live-cd (live-usb)
кэш пакетной системы(той которая устанавливает программы)
Это все должно быть в /var, т.е. на другом физическом диске. А переполнен раздел на диске, куда смонтировано все остальное за исключением var и home. В /etc конечно может что-то меняться, но не гигабайты же.
Плюсую баобаб, удобнейшая вещь. Если нет иксов, то есть NCurses Disk Usage.
На самом деле, «показания» du бывают не слишком актуальны. Иногда df и du показывают совсем разное. du не считает удалённые файлы, с которыми продолжают работать процессы. Их можно глянуть чем-то типа
А что ты конкретно предлагаешь сделать с помощью du? Узнать размеры 10000 файлов?
Узнать размеры каталогов, например
Я уже понял, что ты ламер. Ничего тебе не предлагаю, тебе помогут близкие тебе по духу.
Покажет тебе все файлы, которые изменились за последние сутки
у меня после старта ОС стало всплывать сообщение
После старта! Что будет с удаленными файлами после рестарта?
Грузился. fsck криминала не показал. Хотя gparted показал несколько гигов свободного места на разделе.
«показания» du бывают не слишком актуальны
du не считает удалённые файлы
Чёт тут нестыковка. Если оно не считает то, чего уже нет — где неактуальность?
du запускай. Смонтируй только / в /mnt, например.
затем
1. cd /mnt
2. du -sm * | sort -n
3. затем cd . в самую большую директорию и снова п2.
Баобаб запускал. Сейчас уже не помню, что он там показал. Но, какой смысл в его показаниях. Ну увижу я, сколько места занимают каталоги на корне. Суммарно все сойдется с показаниями df. Это может означать, что где-то есть файлы, которые не ставились с дистриба, или файлы, у которых непонятно отчего вырос размер. Как их искать. Вроде в rpm есть возможность сравнить хэши для реально установленных файлов с хэшами из пакетов. А если показания Баобаба даже не сойдутся с df. То значит глючит ФС. Так?
После старта! Что будет с удаленными файлами после рестарта?
Скажем так. После того, как я удалил пакеты со старой версией ядра, то как минимум ls показал отсутствие образа этого ядра в /boot и соответствующего версии ядра каталога с модулями. Ну и разумеется df показал, что свободного места стало больше. А вот после нескольких перезагрузок (через день-два) свободное место уменьшилось.
Удалённые файлы != то, чего нет. Удалённый файл продолжает занимать место, пока он открыт хотя бы в одном процессе.
Вот это дельная мысль. надо будет попробовать.
И? Процесс завершится и файл удалится окончательно. А у ТС постоянно что-то пишется на диск и там остаётся.
Корень, var и home у меня на разных разделах
А /tmp где ? И во всякие /opt и /srv ничего не ставилось ?
Удалённые файлы != то, чего нет. Удалённый файл продолжает занимать место, пока он открыт хотя бы в одном процессе.
А какое в данном случае это имеет значение? Ну предположим, что удаленный файл был занят процессом. После завершения процесса по какой-то причине место, занимаемое файлом, не освободилось. Ну я удалял бы файлы, а свободного места оставалось столько же, но оно бы не сокращалось само.
А /tmp где ? И во всякие /opt и /srv ничего не ставилось ?
По /tmp и /srv Баобаб показывал какие-то совсем маленькие цифирьки. /tmp, кстати если мне память не изменяет, в ramfs монтируется. Хотя, пожалуй, на /srv стоит обратить повышенное внимание. В /opt я вообще собственноручно ничего не ставил.
/tmp, кстати если мне память не изменяет, в ramfs монтируется
если это указано в fstab, не?
Но пока процесс не завершится, «показания du будут не слишком актуальные».
Сейчас не помню и этого компа рядом нет. Вечером буду смотреть. Интересно, что будет, когда окажется 0 свободного места?
И даже никто не спросил, а сколько у него вообще места в корне?
И даже никто не спросил, а сколько у него вообще места в корне ?
В общем-то, это не очень важно. Туда никто не должен писать, если с него убраны все каталоги, где таковое возможно. То есть, это
основные:
/tmp
/home
/var
/usr/tmp (хотя туда мало кто пишет, да и чаще это симлинк на /var/tmp)
Вроде ничего не забыл. А, /usr/src ещё может быть, если ядра собирать по старой методике, а не опакечивать, или не ставить готовые.
Интересно, что будет, когда окажется 0 свободного места?
Демоны не запустятся → система загрузится в аварийном режиме (возможно, read-only) и попросит пароль рута.
Фигасебе какая софтина, спасибо.
ищешь самые «крупные» папки, идешь далее du -sh /folder/* и тд.
В любом случае придется работать руками, так как только ты знаешь, что в твой системе необходимо и занимает место » с пользой», а что на самом деле раздулось.
может, у тебя почта рута переполнилась? ну, там, лезет кто-то на сервер, а тебе сообщения сыплются про облом авторизации, например. больше ничего вроде на руте и нет такого переполняемого.
а ещё может у тебя своп в файле сделан
Если оно не считает то, чего уже нет — где неактуальность?
Файловые дескрипторы остаются вроде, так что по факту файл есть.
может, у тебя почта рута переполнилась ?
О, точно. В некоторых дистрибутивах почта рута, по-умолчанию, пишется не в /var/spool/mail/, а в
root/, который, опять же, в зависимости от дистрибутива, может оказаться в /root, а не где-то ещё.
Сейчас уже не помню, что он там показал. Но, какой смысл в его показаниях.
Я не пойму, так вам надо узнать чем занято место, или нет?
Ну в общем всем спасибо. Все-таки, когда советуешься с разными людьми, находится кто-нибудь, кто посоветует то, о чем сам забываешь. Хотя все оказывается очевидно, как дважды два. Короче, совет внимательно осмотреть /srv возымел действие. Оказалось именно там bacula «лепила» периодически бэкапы. На каталоге, где сохранялись бэкапы, стояли права, разрешающие доступ только пользователю/группе bacula. Баобаб, конечно, показывал, что /srv практически пуст. Нахрена он автоматически в Mate запускается из-под user-а, если заранее известно, что покажет цифры с потолка? Могли бы предлагать пройти авторизацию, чтобы стартонуть его с правами root-а. Ну и я, конечно, малость тормознул. Bacula я не настраивал. Просто когда-то поставил пакеты с ней до кучи, а ковыряния с настройкой оставил до лучших времен. А потом вообще про неё забыл. А она, оказывается, тихо делала свое дело. Ну а вообще радует хотя бы то, что это не руткит какой-нибудь.
Пользуюсь постоянно командой:
sudo du -xm —max-depth=1 / | sort -rn
где вместо / последовательно вставляю нужные мне пути.
Для того, что бы узнать куда девается место, большего никогда не требовалось,.
Источник
