LINUX.ORG.RU

Куда девается место?


0

1

В продолжение темы.

Несколько часов назад я заметил странную активность HDD и написал сообщение об этом: jbd2: что это? (комментарий) Симптомы те же, что описаны в теме, на которую я оставил ответ. Применил какие-то советы - стало легче.

Потом программы стали ругаться что на диске нет места. Вызвал «Свойства» Konqueror. 0 байт свободно. Странно всё это. Удалил пару файлов по 100-200 Мб. Снова 0 байт свободно.

Раньше я думал что знаю как поступать, когда кончается место на диске. Нужно запустить kdirstat или baobab и посмотреть самые большие файлы и каталоги на диске. Затем удалить ненужное, но давно забытое. Я проделывал это много раз и удалять стало нечего. Ещё недавно было 8 Гб свободного места, и вот опять 0 байт.

Теперь мне нужно знать, какие файлы на диске у меня модифицировались последними. Раз удаление самых больших файлов уже не помогает. Как это сделать? iotop:

Total DISK READ:       0.00 B/s | Total DISK WRITE:     617.50 K/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
14789 be/3 root        0.00 B/s    0.00 B/s  0.00 % 54.58 % [jbd2/sda1-8]
16494 be/4 zenitur     0.00 B/s  117.85 K/s  0.00 %  1.08 % firefox
21367 be/4 zenitur     0.00 B/s   14.73 K/s  0.00 %  0.01 % firefox
    1 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % init [3]
    2 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kthreadd]
    3 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [ksoftirqd/0]
    6 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/0]
    7 be/0 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [cpuset]
    8 be/0 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [khelper]
    9 be/0 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [netns]
15374 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % acpid
15893 be/4 avahi       0.00 B/s    0.00 B/s  0.00 %  0.00 % avahi-dae~neo.local]
15894 be/4 avahi       0.00 B/s    0.00 B/s  0.00 %  0.00 % avahi-dae~oot helper
  535 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [scsi_eh_0]
21423 be/4 zenitur     0.00 B/s    0.00 B/s  0.00 %  0.00 % plugin-co~494 plugin
  550 be/0 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kpsmoused]
14893 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % udevd --daemon
15880 be/4 nobody      0.00 B/s    0.00 B/s  0.00 %  0.00 % dnsmasq -~nsmasq.pid
21427 be/4 zenitur     0.00 B/s    0.00 B/s  0.00 %  0.00 % plugin-co~494 plugin
21769 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % python2.7~otop -d 10
16113 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % -:0
  573 be/0 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [devfreq_wq]

P.S. Только что удалил инсталлятор Little Inferno, который вчера скачал и хотел попробовать. А места уже 250 Мб свободно и стремительно уменьшается.

Перемещено beastie из talks

★★★★★

Последнее исправление: ZenitharChampion (всего исправлений: 2)

какие файлы на диске у меня модифицировались последними

дифф в разное время взятых tree -s -D с корня

но это просто мой дилетантский совет, наверняка есть более профессиональные решения)

science ★★☆
()
Последнее исправление: science (всего исправлений: 1)

смотришь, что сколько занимает в корне, ждёшь, проверяешь ещё раз. когда увидишь, что жрёт, смотришь уже в конкретном каталоге. а вообще, проверь, сколько /var/log весит

xsektorx ★★★
()

Сначала

df -h
чтобы определить где тесно, а затем, например
du -ch /var/log
а также других злачных мест, где ты что-то мог ставить. Полезно было бы пройтись по всем дисковым каталогам верхнего уровня в /

blexey ★★★★★
()
Последнее исправление: blexey (всего исправлений: 1)

Запускай «iotop -aoP». В baobab же должно быть видно, какое место занимает места больше, чем ему полагается.

goingUp ★★★★★
()

в дополнение к предыдущим советам, файл может быть уже удален. тогда его будет видно только в lsof | grep unlinked

val-amart ★★★★★
()
cd /
du -cah -d 1 

смотриш, где у тебя больше всего занято, пеереходишь туда и повторяешь команду, когда найдешь что-нибудь подозрительное, то удаляй

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

find . -type f -amin 30
это выведет список файлов, к которым был доступ в последние 30 минут (созданные). еще есть опция -cmin, покажет измененные файлы.

IvanR ★★★
()

Раз удаление самых больших файлов уже не помогает

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

redgremlin ★★★★★
()

наверно опция -cmin подойдет больше, чем -amin

IvanR ★★★
()
Ответ на: комментарий от IvanR

> cd /
> du -cah -d 1

> смотриш, где у тебя больше всего занято

Это я и из GUI прекрасно делаю последние годы.

> чтобы посмотреть, какие файлы были «тронуты» в последнее время можно выполнить вот такую команду

> find . -type f -amin 30

> это выведет список файлов, к которым был доступ в последние 30 минут (созданные). еще есть опция -cmin, покажет измененные файлы.

Это мне и было интересно! Сейчас попробую.

ZenitharChampion ★★★★★
() автор топика
Последнее исправление: ZenitharChampion (всего исправлений: 1)
Ответ на: комментарий от xsektorx

> смотришь, что сколько занимает в корне, ждёшь, проверяешь ещё раз. когда увидишь, что жрёт, смотришь уже в конкретном каталоге.

Мой вопрос не узнать что сколько занимает - делаю это из GUI много лет - а что последнее менялось на диске. Потому что моя проблема - не большие файлы, вроде забытых образв ISO или HD-роликов с YouTube, а много маленьких файлов по 30 Мб, которые не найти таким способом.

> а вообще, проверь, сколько /var/log весит

В 2010-м нашёл там 2-гигабайтный файл messages. Традиционным способом поиска больших файлов. Это оказалось багом hplip 3.9.8. Он заполнял файл до лимита в 2 гигабайта после возникновения какого-то бага. В следующей версии hplip исправлено.

ZenitharChampion ★★★★★
() автор топика
Последнее исправление: ZenitharChampion (всего исправлений: 2)

ncdu, gdmap

anonymous
()
Ответ на: комментарий от ZenitharChampion

В 2010-м нашёл там 2-гигабайтный файл messages. Традиционным способом поиска больших файлов. Это оказалось багом hplip 3.9.8. Он заполнял файл до лимита в 2 гигабайта после возникновения какого-то бага. В следующей версии hplip исправлено.

у меня в 2011-м подобным образом .xsession-errors забивал всё свободное место в /home. После перезагрузки иксов не повторялось.
И в этот раз у тебя наверное что-то подобное, только бы найти что.

Mosi
()

Может, если systemd стоит и не настроен journald.conf? Дефолтный конфиг настроен по дурацки — вообще не ограничивает размеры логов и уровень логирования. С не настроенным дефолтным конфигом, за 15 минут работы компа, логи журнала могут занять 1.5 гига.

With ★☆☆
()
Последнее исправление: With (всего исправлений: 1)

Если у тебя опенсусе, то это 100% логи генерируемые systemd. У меня когда время загрузки увеличилось в два раза - полез разбираться. Нашел огромные логи. Никем не контролируемые. После чистки и настройки - все вернулось на круги своя. Последние суси - редкое дерьмо, ибо натаскали отовсюду дефолты, но никак их не согласовывали. В результате перелез на Xubuntu - боже, какое оно быстрое и неглючное в сравнении с сусёй.

anonymous
()
Ответ на: комментарий от IvanR

Твоя команда помогла!

# cd /home/zenitur
# find . -type f -ctime -365 > /root/text-home.txt

С помощью неё я получил списочек файлов, созданных за год, А перед этим - за месяц. А перед этим «atime». Освободил много-много гигабайт!!! kdirstat и baobab мне показывают только монстров 10-50 Гб, а сотни файлов 50-500 Мб я не замечал.

ZenitharChampion ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.