- и в то же время MC показывает

sparse files? не слышал! :)
и про количество inodes еще почитай.

я обычно ищу так:

cd /
du -smxc * | sort -nr | head -n 20

дальше смотрю что кажется подозрительным, перехожу туда и опять du

А вообще 2 Tb в / это действительно наивно

Удалённые используемые файлы занимают место.

Оба раза не угадал, дыры в sparse files не занимают место и inodes тут ни при чём

Ха-ха-ха, если у тебя засран диск, обязательно обвини kvm, soft raid и жалко что не Дебиан, ЦентОС, а то бы и Дебиан обвинил во всех смертных грехах.

Ну если ты ламер, то просто перезагрузи host-систему.

Если нет, то запусти lsof и смотри там deleted файлы.

и в то же время MC показывает, что свободного места аж 92 ГБ

файлы уже удалены. du не поможет

Гм. Что-то не понял вас, много противоречивых мнений.
Так какой-то конкретный вывод у вас есть, уважаемые?

файлы уже удалены. du не поможет

Вот прям все удалены? :)

Если какой-то процесс держит удалённый файл, это легко можно увидеть в

sudo lsof | grep -i delete

Файлы давно удалены. После удаления был ребут.
После чего df показал свободного места аж 3,7 ГБ.
Однако всего через 2 дня оно опять уменьшилось до 14 МБ.

Вопрос - почему? Ведь при этом на сервере ничего не делалось, объем, занимаемый виртуалками остался неизменным,
а команда

lsof | grep -i delete

Ужасное поведение сервера с kvm (комментарий)

92 ГБ

намек: это 5% ФС

После чего df показал свободного места аж 3,7 ГБ

ты извини, но 3,7Г - это не «аж», это «ахты ж ёпрст, надо срочно с этим что-то делать».

Однако всего через 2 дня оно опять уменьшилось до 14 МБ

Логи?
Прогони

du -d 1 -h /

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

Почему этого намека не видит df, а только mc?

И вы так и не сказали, кто так жрет пространство.
Неделю назад я удалил в общей сложности порядка 10 ГБ, df показал, что место действительно увеличилось на 10 ГБ, но через неделю оно опять уменьшилось практически до нуля.
Вопрос тот же: who?

chukcha>Хоть и долго, но результат однозначно будет успешным, чем долбание с вашими гребаными LVM и прочими извратами.

молодец, принципиальный

давай ssh root@server я тебе все скажу

Логи?

Конечно, логи смотрел с самого начала, но по сравнению с огромной потерей места они занимают мизерное место, каких-то 22 МБ.

qemu-img info на файлы дисков

Вы меня, конечно, извините за столь крамольную мысль, но мне начинает казаться, что происходит то, что считается в файловых системах Линукс, практически отсутствующим - т.е. фрагментация :(

Так ведь и выходит - измеряешь размеры файлов - порядок, место еще должно оставаться, смотришь место - а его, оказывается, уже и нету..

chukcha, ты читать умеешь? Про du и сортировку уже всё сказано

Вот смотрите, какие изменения показал ncdu за эти 2 дня:

2 дня назад:

[{"name":"images","asize":4096,"dsize":4096,"ino":28575374},
{"name":"win-xp-1.img","asize":107374182400,"dsize":72768589824,"ino":28574151},
{"name":"win-20083.img","asize":1825361100800,"dsize":1765686722560,"ino":28575272},

[{"name":"images","asize":4096,"dsize":4096,"ino":28575374},                                                           
{"name":"win-xp-1.img","asize":107374182400,"dsize":76738293760,"ino":28574151},
{"name":"win-20083.img","asize":1825361100800,"dsize":1765691432960,"ino":28575272},

я же просил выхлоп одной простой команды

и чтоб два раза не вставать, или надо забить диски полностью, чтоб больше не росли, или гонять virt-sparsify

tune2fs -m 2 /dev/md2

- и в то же время MC показывает, что свободного места аж 92 ГБ из 1810 ГБ!

92 гб это как раз 5% из 1810

Прогони

du -d 1 -h /

Что у тебя означает ключик -d ? Его нет в синтаксисе этой команды

и причем тут kvm...

-d 1

глубина depth

Так я уже отвечал: нет ключа "-d"
Вот что отвечает du:

# du -d 1 -h /
du: неверный ключ -- «d»

24M	/lib64
8,0K	/run
0	/sys
du: невозможно получить доступ к «/proc/10452/task/10452/fd/4»: Нет такого файла или каталога
du: невозможно получить доступ к «/proc/10452/task/10452/fdinfo/4»: Нет такого файла или каталога
du: невозможно получить доступ к «/proc/10452/fd/4»: Нет такого файла или каталога
du: невозможно получить доступ к «/proc/10452/fdinfo/4»: Нет такого файла или каталога
0	/proc
238M	/lib
29M	/etc
4,0K	/media
4,0K	/mnt
6,8M	/bin
13M	/sbin
212K	/dev
4,0K	/srv
256K	/root
4,0K	/home
597M	/usr
220K	/tmp
44M	/boot
1,7T	/var
4,0K	/opt
1,7T	/

теперь тоже самое но для /var алгоритм понятен?

Пардон, мне непонятен замысел, цель выполнения этого алгоритма.
Что я должен им достичь - узнать размер самого большого файла? Так я его и так давным давно знаю.
Или тут другое?

Что я должен им достичь - узнать размер самого большого файла? Так я его и так давным давно знаю.

А в чём, в таком случае, заключается твоя проблема, и зачем ты тут мозг людям сношаешь?)

зафрендил

Ты видишь что у тебя /var занимает весь раздел? Скорее всего забивается /var/log. А уж центос, kvm или фрагментация виноваты в том, что ты не настроил logrotate - выясняй сам. Либо, просто пухнут имиджи виртуалок. Вроде, по умолчанию они где-то в недрах /var и создаются, но кто их там держит.

епрст, кто так гипервизоры настраивает

Кривожопость зашкаливает.

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

Отлучить от церкви святого Линуса к чертям!

Э, парни, если бы задача стояла определить, какой из файлов растет и жрет пространство, от я бы к вам с такими детскими вопросами не обращался.

А задача на самом деле посложнее, чем вам с лету показалось.

Еще раз поясняю:
- размеры файлов виртуалок от рождения заданы фиксированными и не растут;
- всевозможные логи занимают ничтожный размер и в поедании пространства уличены никак не могут;
- и наконец, на закуску - размер /var тоже не меняется!

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

Если вы этого до сих понять не можете и даете советы для новичков, то значит, вы такие же наивные ламеры, которым вы пытаетесь представить меня.

размер /var тоже не меняется!

Естественно, куда ему меняться если он уже весь раздел занял.
92 гига которые тебе там кто-то показал - это не свободное место, а херня в пределах погрешности. Корневая фс в таких условиях не работает.

du -h /var --max-depth=1

И таким образом менять /var на /var/log например, исходя из того, в каком каталоге больше всего занятого места.

Что вы этим хотели сказать?

Корневая фс в таких условиях не работает.

В каких таких условиях? 92 ГБ это полно место для ядра.

и наконец, на закуску - размер /var тоже не меняется!

OMG, /var — не отдельная ФС, а директория на /

вы такие же наивные ламеры, которым вы пытаетесь представить меня.

Нет! Только ты!

полно место для ядра.

хYядра. 100G - это 5% от 2T.

Ext3 partition contain a used space of 5% for special reasons by default.

https://wiki.archlinux.org/index.php/Ext3#Reclaim_reserved_filesystem_space

Единственный ламер тут - это ты. «Чукча, однако, не читатель. Чукча - писатель.»

И что вы хотите этим всем сказать - что изначально было запланировано мало места?
Так его полгода было выше крыши, несколько Гигабайт, но которые со временем ужались до 20 Мб.

Ошибки в файловой системе могут как-то влиять на оценку системой дискового пространства?

dyasny, сорри, пропустил ваш вопрос.

Вот выхлоп на виртуальные образы:

qemu-img info /var/lib/libvirt/images/win-20083.img 
image: /var/lib/libvirt/images/win-20083.img
file format: raw
virtual size: 1.7T (1825361100800 bytes)
disk size: 1.6T

# qemu-img info /var/lib/libvirt/images/win-xp-1.img 
image: /var/lib/libvirt/images/win-xp-1.img
file format: raw
virtual size: 100G (107374182400 bytes)
disk size: 71G

И что вы хотите этим всем сказать - что изначально было запланировано мало места?

Мы этим всем хотим сказать, что

a) Для файловой системы (любой) режим нормального функционирования - это когда занято 80-85% (максимум). Хочешь больше - изучай используемую файлуху, применяй тюнинг;

b) на / образы виртуалок размещают только мудаки^Wочень недалёкие люди.

c) в данной теме тебе об этом писали уже, по меньшей мере, дважды. «Не читатель», хуле.

win-20083.img

win-xp-1.img

Поставь уже винду и не мучай птицу пингвина.

b) на / образы виртуалок размещают только мудаки^Wочень недалёкие люди.

А кто тебе сказал, что образы в корне? Они в варе:

image: /var/lib/libvirt/images/win-20083.img

df показывает такую картину:

Filesystem      Size  Used Avail Use% Mounted on
/dev/md2        1,8T  1,7T   14M 100% /
tmpfs            24G     0   24G   0% /dev/shm
/dev/md1        496M   54M  417M

А кто тебе сказал, что образы в корне? Они в варе

Где?

В варе, /var

/var/lib/libvirt/images/win-20083.img

На каком блочном устройстве расположен /var?

На том же, что и /root, и корень, и все остальное, кроме /boot.

Если ты хочешь сказать, что такая разбивка ущербная - да ладно тебе!
Я больше 10 лет так размещаю так веб-сервера, и не один я, но подобных описанной проблем не возникает.
Чем виртуальные одно-файловые образы виртуалок капризнее, чем сотни тысяч html-страниц?

А кто тебе сказал, что образы в корне? Они в варе

На каком блочном устройстве расположен /var?

На том же, что и /root, и корень, и все остальное

Впервые вижу такого упорыша, ей-богу. Можешь не отвечать.

Из уважения к народам крайнего севера последняя попытка. Читай медленно и пытайся понять

Тебе уже 10 раз сказали - у тебя есть проблема, там возьми и мать твою начни её решать, а не ныть и не требовать от каких-то телепатов сделать всё за тебя.

Кто-то жуткими темпами жрет пространство, но кто именно, непонятно.

Жуткими темпами - это сколько в байтах за день? Берёшь, смотришь сколько что занимает сейчас. В байтах! Тот же 'du -sbxc *' - find ты явно не осилишь. Когда очередной раз вырастет жуткими темпами - берёшь и смотришь ещё раз. И сравниваешь. Цель - найти того, кто это место занял

Есть быстрый спосов, который уже озвучен здесь, но он требует наличия головного мозга. Идёшь в корень. Смотришь du -smxc | sort -nr | head -n 20 . По каждой строке смотришь, сколько места занято, а сколько по твоим расчётам может занять. Несоответствие? Идём в этот каталог и опять же проверяем. Либо. Снова смотрим, «с жуткой скоростью» - это сколько? В этом каталоге поместиться может? А в этом?

Теперь про твои косяки

1. Свалить всё в корень, все 2 Тб - это дно, днище, и дальше просто некуда. На тебя даже erzent будет смотреть как на беспросветного ламера. ОСь отдельно, данные отдельно. Начиная от роста файлов, на который ты напоролся, заканчивая риском повреждения ФС при внезапном отключении питания ( раз уж горячие данные лежат на ФС, то это должна быть отдельная ФС )

2. Непонимание принципов работы ФС ext. Как уже сказали, 5% - это стандартный резерв для рута, чтобы он всегда мог зайти в систему, даже если кто-то забил весь диск. Твой бред по фрагментацию даже комментировать не буду

3. Непонимание, что такое overhead, и как считать потребность в ресурсах.

4. Непонимание того, что это твоя проблема, тебе её нужно решать, и никто тебе ничего не должен. Ты спросил совета, тебе нужно включить голову и пытаться понять, что ответили. А не требовать прийти к единому мнению, сделать всё за тебя, а потом ещё и подгузник тебе сменить

5. «размеры файлов виртуалок от рождения заданы фиксированными и не растут;» - ложь, и ты уже запостил опровержение. google sparse files

6. Предвзятое отношение к LVM. LVM имеет защиту от дурака, что в данном случае было бы весьма кстати и защитило бы тебя от тебя. Кроме того, LVM даёт существенно меньший overhead, чем файловая система. Как по дисковому пространству, так и по производительности

Напоследок хотелось бы привести цитату из старого выпуска журнала upgrade, который я читал лет 15 назад, когда учился в школе

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

В догонку к п.3. Прежде, чем обещать сервису какой-то ресурс, убедись что этот ресурс у тебя есть. Почитай про разницу GB и GiB. Потом попробуй узнать что-нибудь про погрешность измерений. Если неизвестная тебе утилита пишет 1.7 Tb, это может быть и 1.7 TiB ровно, и 1.65 TB