Куда может пропасть свободное место на HDD?

Question

[Дмитрий]

Добрый день!
Есть удалённый сервер с raid 1 (ext3) на debian
Если смотреть по каталогам, то
du / -h --max-dept=1
763G /
А если df -h
/dev/disk/by-uuid/ 1.8T 1.6T 145G 92% /
Расхождение примерно в 800 гиг.
Подскажите пожалуйста, что я не учёл, как посмотреть ещё.

Comments

[Евгений]

весь df -h покажите

[Дмитрий]

Nc_Soft:
Filesystem Size Used Avail Use% Mounted on
udev 10M 0 10M 0% /dev
tmpfs 3.2G 368K 3.2G 1% /run
/dev/disk/by-uuid 1.8T 1.6T 145G 92% /
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 9.5G 34M 9.5G 1% /run/shm
/dev/md1 496M 108M 363M 23% /boot
/dev/fuse 30M 12K 30M 1% /etc/pve

Answer 1

[Сергей Петриков]

ncdu / еще посмотрите.
Место уходит в никуда, когда диск сыплется и часть секторов помечаются системой как сбойные.

Comments

[Дмитрий]

Спасибо, не знал ещё такой утилиты. К сожалению она показывает одинаковый результат с du. SMART (smartctl ) то же пишет что ошибок нет.

[Сергей Петриков]

mialon: Так еще гляньте
badblocks -v /dev/hda1 но желательно в синглюзере.

[Дмитрий]

Сергей Петриков: Спасибо, проверю, как закончится отпишусь

[Дмитрий]

Сергей Петриков: Pass completed, 0 bad blocks found. (0/0/0 errors) к сожалению не помогло

Answer 2

[Дмитрий]

Спасибо всем за ответы. Узнал много интересного. Что было так и не понял, просто переустановил сервер(благо это linux) и проблема пропала. Буду надеяться что она не повторится.

Answer 3

[Армянское Радио]

uptime большой? Файлы удаляли? Дело в том, что в linux, в отличие от windows, имя файла и его inode - раздельные сущности, и если стереть открытый файл, он вроде как из ФС пропадет, но место не освободится, пока его процесс не закроет.

Comments

[Сергей Петриков]

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

[Дмитрий]

Файлы удалял, но не настолько же) Перезагружал его недавно, все процессы сбросились.

[Игорь]

Что-то, куда-то писало или пишет, потом файл удалили, а процесс не перезапустили. В итоге запись идет все в тот же inode.
Попробуйте lsof поискать кто это может. Если найти процесс не получится, можно попробовать перезагрузить сервер (если такая возможность есть), чтобы все процессы перезапустились.

[Дмитрий]

Игорь: Как я писал выше, сервер перезагружал, ситуация не изменилась, к сожалению.

Answer 4

[Влад Животнев]

lsof | grep deleted говорит что-нибудь?

Ещё как вариант - что у вас там nginx накешировал на 800 гигов чего-нибудь (эти файлы в du не попадают). Ну или кто-то ещё, кроме nginx-а.

Comments

[Дмитрий]

Да, список большой. Не знал что кеш nginx не попадает в du. Не подскажите что делать?

[Влад Животнев]

> список большой
перезапустите процессы, которые эти файлы используют

> Не знал что кеш nginx не попадает в du. Не подскажите что делать?
разбираться, почему он кэширует несколько сотен гигабайт)

[Дмитрий]

Влад Животнев: Весь сервер перезапускал. Папка кеша (/var/cache/nginx) занимает 4 мега. Удалил всё, результата нет.

Answer 5

[Пума Тайланд]

сделайте лучше
cd /
du -s * | sort -n

Comments

[Дмитрий]

Ну так проще смотреть конечно, но ситуацию это не изменило, занято всего 760 гигов

[Пума Тайланд]

mialon: reboot делали :?

[Дмитрий]

Пума Тайланд: Да, конечно

Answer 6

[O Di]

В /var/log случайно вакханалия не творится?

Comments

[Дмитрий]

Это первое что я проверяю) Там все нормально

Answer 7

[giner]

Попробуйте ключ запустить du с ключом --apparent-size и без него:

sudo du -xsh --apparent-size /
sudo du -xsh /

Ещё посмотрите какой процент блоков зарезервирован для root:

$ sudo dumpe2fs -h /dev/sda1 | grep -i "block count"
Block count:              7323904
Reserved block count:     366195
$ calc 366195/7323904
	~0.04999997269215980985

"lsof | grep deleted" - тоже хороший совет уже упомянутый выше