Диск повний, du розповідає різні. Як далі розслідувати?

У мене на сервері диск SCSI (апаратний Raid 1), 32G, файловий файл ext3. dfговорить мені, що диск на 100% заповнений. Якщо я видаляю 1G, це правильно показано.

Однак, якщо я запускаю a, du -h -x /тоді duмені кажуть, що використовується лише 12G (я використовую -xчерез деякі кріплення Samba).

Отже, моє запитання полягає не в тонких відмінностях команд du і df, а в тому, як я можу дізнатися, що викликає цю величезну різницю?

Я перезавантажив машину для fsck, який вийшов без помилок. Чи варто бігати badblocks? lsofне показує мені жодних відкритих видалених файлів, lost+foundпорожній і у файлі повідомлень немає явного попередження / помилки / помилки.

Не соромтеся запитати більш детальну інформацію про налаштування.

Перевірте наявність файлів, розташованих під точками кріплення. Якщо ви монтуєте каталог (скажімо, самбафс) на файлову систему, в якій вже був файл або каталоги, ви втрачаєте можливість переглядати ці файли, але вони все ще займають місце на базовому диску. У мене були копії файлів, перебуваючи в єдиному користувальницькому режимі, скидайте файли в каталоги, які я не міг бачити, за винятком єдиного користувальницького модуля (через інші системи каталогів, що монтуються поверх них).

Щойно натрапив на цю сторінку, намагаючись відстежити проблему на локальному сервері.

У моєму випадку df -hі du -shнезбіжні приблизно 50% від розміру жорсткого диска.

Це було спричинено тим, що apache (httpd) зберігав великі файли журналів у пам'яті, які були видалені з диска.

Це було відстежено, пробігши, lsof | grep "/var" | grep deletedде /varбув розділ, який мені потрібно було прибрати.

Вихідні дані показали такі рядки:
httpd 32617 nobody 106w REG 9,4 1835222944 688166 /var/log/apache/awstats_log (deleted)

Потім ситуацію було вирішено перезапуском apache ( service httpd restart) та очищено 2 Гб дискового простору, дозволивши очистити блокування видалених файлів.

Я погоджуюся з відповіддю OldTroll як найбільш вірогідною причиною вашого "пропущеного" простору.

У Linux ви можете легко відновити весь кореневий розділ (або будь-який інший розділ для цього питання) в інше місце у вашій файловій системі rec / mnt, наприклад, просто видайте

mount -o bind / /mnt

тоді ви можете зробити

du -h /mnt

і подивіться, що використовує ваш простір.

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

Подивіться, що df -iговорить. Можливо, у вас немає індексів, що може статися, якщо в тій файловій системі є велика кількість невеликих файлів, які використовують усі доступні вставки, не витрачаючи всього наявного місця.

У моєму випадку це стосувалося великих видалених файлів. Доволі болісно було вирішити, перш ніж я знайшов цю сторінку, яка поставила мене на правильний шлях.

Нарешті я вирішив проблему за допомогою програми lsof | grep deleted, яка показала мені, яка програма містить два дуже великі файли журналу (загалом 5 ГБ мого доступного кореневого розділу 8 ГБ).

Файли, відкриті програмою, насправді не відходять (припиняють витрачати місце на диску), коли ви видаляєте їх, вони відходять, коли програма їх закриває. У програмі може бути величезний тимчасовий файл, який ви (і ду) не можете бачити. Якщо це програма для зомбі, можливо, вам доведеться перезавантажити, щоб очистити ці файли.

Спробуйте це, щоб побачити, чи заблокований мертвий / вивішений процес під час запису на диск: lsof | grep "/ mnt"

Потім спробуйте знищити будь-які PID, які застрягли (особливо шукайте рядки, що закінчуються на "(видалено"))

Це найпростіший метод, який я знайшов на сьогодні, щоб знайти великі файли!

Ось приклад, якщо кореневе кріплення повне / (mount / root) Приклад:

CD / (значить, ви в корені)

лс | xargs du -hs

Приклад Вихід:

 9,4 млн. Кошика
 63M черевик
 4,0K група
 680K дев
 31М тощо
 6.3G додому
 313M lib
 32M lib64
 16K втрачено + знайдено
 61G медіа
 4,0K мнт
 113M опт
 du: не може отримати доступ до `proc / 6102 / task / 6102 / fd / 4 ': такого файлу чи каталогу немає
 0 проц
 19M корінь
 840K пробіг
 19М сбін
 4.0K selinux
 4,0K серв
 Магазин 25G
 26М тм

то ви помітили б, що магазин великий - це компакт-диск / магазин

і знову біжи

лс | xargs du -hs

Приклад виводу: 
 Резервне копіювання 109M
 358M fnb
 4.0G iso
 8,0 Кс
 16K втрачено + знайдено
 47M корінь
 11М сценаріїв
 79М тм
 21G vms

у цьому випадку каталог vms - це космічна свиня.

Для мене мені потрібно було запустити, sudo duоскільки було велика кількість файлів docker, під /var/lib/dockerякими користувач, який не користується судом, не має дозволу на читання.

Ще одна можливість врахувати - ви майже гарантовано побачите велику невідповідність, якщо використовуєте docker, і запускаєте df / du всередині контейнера, який використовує кріплення гучності. У випадку каталогів, встановлених у томі на хості докера, df повідомить про підрахунки df HOST. Це очевидно, якщо ви думаєте про це, але коли ви отримуєте звіт про "втікаючий контейнер, що заповнює диск!", Переконайтеся, що ви перевірили споживання файлового простору контейнера чимось подібним du -hs <dir>.

Тож у мене виникла ця проблема і в Centos 7, і я знайшов рішення, спробувавши купу речей, таких як bleachbit та очищення / usr та / var, хоча вони показали лише по 7G кожен. Досі показував 50G 50G, що використовується в кореневому розділі, але показав лише 9G використання файлів. Запустив живий ubuntu CD і відключив порушуваний 50G розділ, відкрив термінал і запустив xfs_check та xfs_repair на розділ. Потім я переказав розділ, і мій загублений + знайдений каталог розширився до 40G. Сортував втрачений + знайдений за розміром і знайшов 38G текстовий файл журналу для пари, який, можливо, просто повторив помилку у форматі mp3. Вилучено великий файл і тепер є місце, і використання моїх дисків відповідає моєму розміру кореневого розділу. Я все одно хотів би знати, як зробити так, щоб паровий журнал знову не став таким великим.

якщо змонтований диск є загальною папкою на машині Windows, то, здається, df покаже розмір та використання диска всього диска Windows, але du покаже лише ту частину диска, до якої ви також маєте доступ. (і монтується). тому в цьому випадку проблема повинна бути виправлена ​​на машині Windows.

Схожа річ трапилася і у нас із виробництвом, використання диска вийшло на 98%. Провели таке розслідування:

a) df -iдля перевірки використання inode використання inode становило 6%, тому не набагато менші файли

б) Монтаж rootта перевірка прихованих файлів. Не вдалося завантажити зайві файли. duрезультати були такі ж, як і перед монтуванням.

в) Нарешті, перевірені nginxжурнали. Він був налаштований для запису на диск, але розробник видалив файл журналу безпосередньо, викликаючи nginxзбереження всіх журналів у пам'яті. Оскільки файл /var/log/nginx/access.logбув видалений з диска, використовуючи rmйого, його не було видно за допомогою, duале файл отримував доступ до нього, nginxа значить, він все ще був відкритим

У мене була та сама проблема, яка згадується в цій темі, але в одній VPS. Тому я перевірив все, що описано в цій темі, але без успіху. Рішення було контактом для підтримки з нашим провайдером VPS, який здійснив перерахунок квот і виправив різницю в просторі df -hта du-sh /.

Я зіткнувся з цією проблемою на вікні FreeBSD сьогодні. Проблема полягала в тому, що це артефакт vi( vimне впевнений, чи vimстворить цю проблему). Файл займав багато місця, але повністю не був записаний на диск.

Ви можете перевірити це за допомогою:

$ fstat -f /path/to/mount/point |sort -nk8 |tail

Це розглядає всі відкриті файли та їх сортування (чисельно через -n) 8-м стовпцем (клавіша, -k8), де відображаються останні десять елементів.

У моєму випадку остаточний (найбільший) запис виглядав так:

bob      vi         12345    4 /var      97267 -rwx------  1569454080 rw

Це означало, що процес (PID) 12345 витрачав 1,46G (восьмий стовпчик, розділений на 1024³) диска, незважаючи на відсутність duйого помічання . viжахливо переглядати надзвичайно великі файли; навіть 100 Мб для нього великий. 1.5G (або наскільки великий файл насправді був) є смішним.

Рішення полягало в тому, щоб sudo kill -HUP 12345(якщо це не вийшло, я б sudo kill 12345і якщо це теж не вдалося , боязнь kill -9прийде в гру).

Уникайте редакторів тексту на великих файлах. Зразок способу вирішення для швидкого скимінгу:

Припускаючи розумні довжини рядків:

• { head -n1000 big.log; tail -n1000 big.log } |vim -R -
• wc -l big.log |awk -v n=2000 'NR==FNR{L=$1;next}FNR%int(L/n)==1' - big.log |vim -R -

Припускаючи необґрунтовано великі рядки:

• { head -c8000 big.log; tail -c8000 big.log } |vim -R -

Вони використовуються vim -Rзамість того, viewщо vimмайже завжди краще ... коли він встановлений. Не соромтеся подавати їх у viewабо vi -Rзамість цього.

Якщо ви відкриваєте такий великий файл, щоб його фактично редагувати, розгляньте sedчи awkінший програмний підхід.

перевірте, чи на вашому сервері встановлений агент ossec. Або якийсь процес використовує видалені файли журналу. У моєму часі тому був агентом ossec.

Перевірте / загублений + знайдений, у мене була система (centos 7), а частина файлу в / lost + знайшла з'їдений весь простір.