Сообщается, что раздел заполнен, но я не могу его видеть & rdquo; любые преступные файлы

Итак, вот сделка:

- df сообщает о 100% использовании на разделе, где размещаются мои / домашние каталоги (и только те)

- Инструменты, которые используют du (a la baobab или xdiskusage) сообщают, что чрезмерное потребление пространства явно связано с моим пользователем.

- Инструменты, которые используют du, делают not , однако, похоже, могут найти любые файлы, которые являются виновниками. Например, xdiskusage показывает, что мой профиль занимает> 260 ГБ, но только приблизительно половину объема данных в файлах (остальное отображается как просто пустое пространство).

- Запуск du в CLI просто показывает то, что я описал выше: папка ~ / user моего пользователя потребляет вдвое больше дискового пространства, чем на самом деле имеет файлы внутри.

И мой любимый:

- -Это, похоже, коррелирует с временем безотказной работы, как будто какой-то процесс медленно заполняет раздел данными до тех пор, пока диск не будет заполнен. И когда я перезагружу - pooof! тонны свободного пространства. Есть ли инструмент интроспекции, который позволил бы мне выяснить, например, какой процесс записывается на диск в любой момент времени?

Любые предложения?

3
задан 23 October 2011 в 06:55

4 ответа

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

Из-за как работает файловая система Unix, приложение может открыть файл, а затем отключить его (т. е. удалить запись имени файла из его родительского каталога). Файл-дескриптор по-прежнему остается действительным, хотя с ним не связано имя файла, и приложение все еще может писать в файл, потому что дескриптор указывает на индексный дескриптор, а не на имя файла.

Такой файл существует до тех пор, пока приложение не закроет его. Я понимаю, что это обычный способ создания «частного» временного файла для приложения.

Чтобы найти такие файлы, используйте

lsof +L

, который покажет вам номер ссылок на каждый открытый файл (столбец NLINK) - в несвязанных файлах есть 0. Вот как выглядит несвязанный файл:

COMMAND     PID       USER   FD      TYPE             DEVICE SIZE/OFF NLINK       NODE NAME
...
mysqld     1126      mysql   11u      REG                8,1        0     0   33603687 /tmp/ibMlwWQA (deleted)
3
ответ дан 6 August 2018 в 02:56

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

Из-за как работает файловая система Unix, приложение может открыть файл, а затем отключить его (т. е. удалить запись имени файла из его родительского каталога). Файл-дескриптор по-прежнему остается действительным, хотя с ним не связано имя файла, и приложение все еще может писать в файл, потому что дескриптор указывает на индексный дескриптор, а не на имя файла.

Такой файл существует до тех пор, пока приложение не закроет его. Я понимаю, что это обычный способ создания «частного» временного файла для приложения.

Чтобы найти такие файлы, используйте

lsof +L

, который покажет вам номер ссылок на каждый открытый файл (столбец NLINK) - в несвязанных файлах есть 0. Вот как выглядит несвязанный файл:

COMMAND     PID       USER   FD      TYPE             DEVICE SIZE/OFF NLINK       NODE NAME
...
mysqld     1126      mysql   11u      REG                8,1        0     0   33603687 /tmp/ibMlwWQA (deleted)
3
ответ дан 7 August 2018 в 20:37

Любопытная часть - это то, как это изменяется со временем, а затем исчезает, когда вы выходите из системы. Подробнее об этом через минуту.

Как вы работаете в режиме, который учитывает скрытые файлы в вашем домашнем каталоге? Например, сравните вывод следующих двух команд, запускаемых из вашего домашнего каталога:

(home)$ du -csxk *
(home)$ du -csxk .

Форма «точка» всегда должна быть больше. Гораздо больше, и вы знаете, что ваше дополнительное пространство находится в скрытом файле.

попробуйте следующее из $ HOME:

(home)$ find . -maxdepth 1 -print0 | xargs -0 du -cskx --exclude .gvfs | sort -rn

(я исключаю .gvfs, потому что именно там gnome монтирует удаленные файловые системы.)

Это должно верните список всех каталогов, включая скрытые, отсортированные по убыванию. Общая линия и ваш дом (.) Должны быть наверху, и поскольку вы делаете грандиозную сумму, общая линия должна быть примерно в два раза больше вашего домашнего размера.

Здесь вы можете начать бурение в большие каталоги (мой гигантский грохот большой) ищет преступников.

Теперь о скоррелированной по времени части этого. Во-первых, давайте посмотрим, сможете ли вы увидеть изменения размеров при входе в систему:

(home)$ watch -n 10 'find . -maxdepth 1 -print0 | xargs -0 du -csxk --exclude .gvfs | sort -rn'

Это приведет к выполнению команды каждые 10 секунд, поэтому вы можете надеяться, что со временем все изменится. Следующее, что нужно сделать, это попытаться увидеть, как хранилище возвращается при выходе из системы. Сделайте второго пользователя-администратора (вам нужны привилегии sudo) и войдите в систему как пользователь через удаленный компьютер или что-то в этом роде. Как этот пользователь, sudo to root и cd в ваш дом и снова запустите последнюю команду, наблюдая за чем-то, что нужно изменить при выходе и входе в систему.

1
ответ дан 15 August 2018 в 21:48

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

Из-за как работает файловая система Unix, приложение может открыть файл, а затем отключить его (т. е. удалить запись имени файла из его родительского каталога). Файл-дескриптор по-прежнему остается действительным, хотя с ним не связано имя файла, и приложение все еще может писать в файл, потому что дескриптор указывает на индексный дескриптор, а не на имя файла.

Такой файл существует до тех пор, пока приложение не закроет его. Я понимаю, что это обычный способ создания «частного» временного файла для приложения.

Чтобы найти такие файлы, используйте

lsof +L

, который покажет вам номер ссылок на каждый открытый файл (столбец NLINK) - в несвязанных файлах есть 0. Вот как выглядит несвязанный файл:

COMMAND     PID       USER   FD      TYPE             DEVICE SIZE/OFF NLINK       NODE NAME
...
mysqld     1126      mysql   11u      REG                8,1        0     0   33603687 /tmp/ibMlwWQA (deleted)
3
ответ дан 15 August 2018 в 21:48
  • 1
    если кто-то задается вопросом, как избавиться от таких файлов, я считаю, это может помочь. Для меня уничтожение перечисленных там процессов решило проблему. – Matthias 22 August 2016 в 13:58

Другие вопросы по тегам:

Похожие вопросы: