LINUX.ORG.RU
ФорумAdmin

Шагреневая кожа закончилась :(

 


0

1

Эта проблема началась в августе 2015 г. и тогда закончилась ничем хорошим. Т.е.: я так и не мог ее решить.
Напомню: на сервере под управлением CentOS 6 все время уменьшалось свободное дисковое пространство - Ужасное поведение сервера с kvm
Как только не пытался решить эту проблему, в том числе и с вашей помощью, ничего не вышло.
Между тем свободное место все уменьшалось и уменьшалось, но за счет чего - по сей день непонятно.

Пришлось прибегнуть к очевидному, но безграмотному способу - отнимать и добавлять.
Т.е. - отнимал от зарезервированного под /root место в 5% и добавлять в общее дисковое пространство.

Наконец, сегодня и это место исчерпалось -

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

Всё, что можно было, вычищено. Сервер под угрозой установки.
Вопрос: найдется ли на ЛОРе человек, который без бла-бла, тыканий в мануалы и прочие RTFM может помочь практически в решении этой непонятной проблемы?

★★★★★

чем помочь-то? Советом или железом?

Удалённые открытые файлы по-факту занимают место до тех пор, пока процесс не отпустит. Кажется, тебе надо lsof, вычислить процесс и ребутнуть его.

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

Тебе в том треде все сказали. Вычищай все чтобы хотябы треть диска была свободна и все.

Deleted
()

du -kx | egrep -v «\./.+/» | sort -n

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

чем помочь-то? Советом или железом?

Помочь выявить причину, по которой постоянно уменьшается свободное пространство

Вычищай все чтобы хотябы треть диска была свободна и все.

С радостью! Только подскажите, от чего именно почистить? От всего, чего знал, уже давно почистил

du -kx | egrep -v «\./.+/» | sort -n

Выложил здесь: http://www.heypasteit.com/clip/2FVT

chukcha ★★★★★
() автор топика

который без бла-бла, тыканий в мануалы и прочие RTFM может помочь практически в решении этой непонятной проблемы?

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

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

Кажется, тебе надо lsof, вычислить процесс и ребутнуть его.

А если я полностью ребутаюсь - это еще лучше?

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

ты на результат «du -kx | egrep -v «\./.+/» | sort -n» посмотрел ?

Без этого нет смысла дальше что-либо делать.

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

До самого конца. Но что толку? У меня подобных «снимков» скопилась уже уйма, по месяцам, но понять из них, что вызывает уменьшение пространства, не могу.
То, что видишь ты, я могу не видеть.
Поэтому лучше скажи, что ты в нем видишь такого особенного?

chukcha ★★★★★
() автор топика

ктооо???!!! кто доверил тебе админить что-то?! ТЫ ЖЕ ТУПОЙ, СУКА, ТУПОЙ!

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

А, вот оно в чем дело! :) Т.е. ты хочешь сказать, что свободное место скушали эти друзья?

1857596008      ./libvirt/images
1857596064      ./libvirt
1857651456      .
Эх, да если бы всё было так просто... тогда бы я и не обращался к вам за помощью.

Но понимаешь ли, какая штука... эти images давно достигли указанного им при настройке kvm предела и давно не растут.
А вот место на харде - все равно постоянно уменьшается - почему, за счет чего?
Вот это и есть самый главный вопрос.

du -hs /var/log
25M     /var/log
chukcha ★★★★★
() автор топика
Последнее исправление: chukcha (всего исправлений: 1)
Ответ на: комментарий от vel

Вот, пожалуйста -

lsof -n | egrep '(REG|DEL).*/var/log'
auditd     1380      root    5w      REG                9,2       5213032   28574391 /var/log/audit/audit.log
rsyslogd   1402      root    1w      REG                9,2          1419   28574253 /var/log/messages
rsyslogd   1402      root    2w      REG                9,2         38798   28574224 /var/log/cron
rsyslogd   1402      root    4w      REG                9,2          1844   28574135 /var/log/secure
libvirtd   1785      root    4w      REG                9,2         36526   28575256 /var/log/libvirt/libvirtd.log
qemu-kvm   1967      qemu    1w      REG                9,2         25607   28704778 /var/log/libvirt/qemu/win-xp-1.log
qemu-kvm   1967      qemu    2w      REG                9,2         25607   28704778 /var/log/libvirt/qemu/win-xp-1.log
qemu-kvm   2001      qemu    1w      REG                9,2         46616   28705053 /var/log/libvirt/qemu/win-20083.log
qemu-kvm   2001      qemu    2w      REG                9,2         46616   28705053 /var/log/libvirt/qemu/win-20083.log

chukcha ★★★★★
() автор топика

Выложи свой контакт. Я с тобой свяжусь и попробуем решить твою проблему.

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

Вот число 1857596008 это ведь в килобайтах. Сколько это будет в Терабайтах?

эти images давно достигли указанного им при настройке kvm предела и давно не растут.

Если он были sparse-файлами, то ″ls -l″ выводит не тот размер, который они занимают на диске.

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

Но понимаешь ли, какая штука... эти images давно достигли указанного им при настройке kvm предела и давно не растут. А вот место на харде - все равно постоянно уменьшается - почему, за счет чего? Вот это и есть самый главный вопрос.

Посмотрите разницу между «ls -l» и «du» скорее всего вы увидете что чудесным образом размер файла с образом БОЛЬШЕ чем фактически занимаемое место на диске.

Это значит что файлы для образа создавались как sparse файлы - тоесть в все не заполненые области (содержащие нули) не хранятся физически на диске. Теперьже когда гостевая ОС работает и чтото пишет на свой виртуальный диск файловая система начинает выделять физические блоки под эти данные.

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

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

А тут, оказывается, поджидает уже несколько советов.
Испробовал этот -

Посмотрите разницу между «ls -l» и «du» скорее всего вы увидете что чудесным образом размер файла с образом БОЛЬШЕ чем фактически занимаемое место на диске.

Ок, попытался вычислить объем этих файлов по ls -l :

258 Авг 29 20:57 du_images_2015-08-29_21-56.txt
258 Авг 30 18:01 du_images_2015-08-30_19-01.txt
296 Сен 10 16:09 du_images_2015-09-10_17-09.txt
330 Сен 11 21:30 du_images_2015-09-11_22-30.txt
366 Дек  5 14:57 du_images_2015-12-05_15-56.txt
403 Фев  4 20:09 du_images_2016-02-04_21-11.txt
71 Авг 28 21:26 ru_windows_xp_professional_with_service_pack_3_x86_cd_vl_x14-74146.iso
71M Окт 22  2014 virtio-win-0.1-81.iso
1,7T Фев  5 01:21 win-20083.img
100G Фев  5 00:30 win-xp-1.img
Получилось:
1982 + 71*1024*1024 + 1.7*1024*1024*1024*1024 + 100*1024*1024*1024 = 
1982 + 74448896  + 8,46623953388e+12 ???
т.е. gcalculator не осилил третье слагаемое, выдав произведение через натуральное основание, поэтому плюнул на эти хитроумные расчеты.
А на бумажке перемножать ну его нафиг, обязательно где-то ошибусь.

Важнее другое - сегодня впервые услышал об sparse-файлах.
Спасибо, это действительно пробел в моем воспитании :(
Мне неизвестно, используется ли эта технология при работе kvm-имиджей.
Но если да, то похоже, она объясняют систематическое разрастание размера файлов.
Возможно, это полезная штука, но в данном случае она оказалось миной замедленного действия.
Но тогда кто-то в системе должен увидеть это явление и правильно показать - ls или кто?
В-общем, загадка осталась загадкой.

Выложи свой контакт. Я с тобой свяжусь и попробуем решить твою проблему.

bryak, спасибо за желание помочь. Связаться со мной можно через одноименный ник на https://fastzone.net , а там дальше разберемся.

chukcha ★★★★★
() автор топика
Последнее исправление: chukcha (всего исправлений: 1)
Ответ на: комментарий от chukcha
1982 + 71*1024*1024 + 1.7*1024*1024*1024*1024 + 100*1024*1024*1024 = 1930291406KB

du у Вас показывает 1857596008KB, тоесть еще почти 70G не выделенных блоков под эти файлы Но это может оказатся не правдой, так как 1.7 - число очень сильно округленное, для верности покажите

stat win-20083.img
stat win-xp-1.img
du win-20083.img
du win-xp-1.img

PS сщитать удобней (по крайней мере для меня) в консоле с помощью команды «bc -l»

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

Это пожалуйста -

stat win-20083.img 
  File: «win-20083.img»
  Size: 1825361100800	Blocks: 3536481184 IO Block: 4096   обычный файл
Device: 902h/2306d	Inode: 28575272    Links: 1
Access: (0600/-rw-------)  Uid: (  107/    qemu)   Gid: (  107/    qemu)
Access: 2016-02-05 03:09:28.572525635 +0100
Modify: 2016-02-05 03:31:07.503318377 +0100
Change: 2016-02-05 03:31:07.503318377 +0100

stat win-xp-1.img 
  File: «win-xp-1.img»
  Size: 107374182400	Blocks: 178567664  IO Block: 4096   обычный файл
Device: 902h/2306d	Inode: 28574151    Links: 1
Access: (0600/-rw-------)  Uid: (  107/    qemu)   Gid: (  107/    qemu)
Access: 2016-02-05 02:08:25.953486069 +0100
Modify: 2016-02-05 02:08:25.924486789 +0100
Change: 2016-02-05 02:08:25.924486789 +0100

du win-20083.img 
1768240592	win-20083.img

du win-xp-1.img 
89283832	win-xp-1.img

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

Ну вот теперь видно что win-20083.img еще может «потребить»

((1825361100800/1024) - 1768240592) / (1024*1024) = 13.67GB

А win-xp-1.img

((107374182400/1024) - 89283832) / (1024*1024) = 14.85GB

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

Важнее другое - сегодня впервые услышал об sparse-файлах.

Перечитал твой предыдущий тред. Впервые услышал. Удивительно.

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

Разгадка:

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

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

Ну вот теперь видно что win-20083.img еще может «потребить»

Интересно, а qemu-img info этого не покажет?

Davyd ★★
()

Ну вот, только сегодня решил эту проблему.
Но как решил - поскольку свободного места всё равно не было, пришлось удалить имидж виртуалки XP размером в 100 ГБ и установить XP заново, но уже размером в 40 ГБ.

Причем, вначале создал диск/имидж динамического типа, поскольку в «Менеджере виртуальных машин» v.1.0.1 от Debian 8 видимо, был косяк - опция "Использовать весь диск" не включалась.

Тогда вернулся к прежнему менеджеру v.0.9.0 от CentOS 6.
На нем без проблем без проблем задал опцию " «Использовать весь диск», и создал диск/имидж фиксированного размера, тоже 40 ГБ.

В завершение удалил динамический диск/имидж в 40 ГБ, и снова был ошарашен - потому что свободное увеличилось не на 40 ГБ, как можно было ожидать, а всего на 3 ГБ!!!

Короче - эти sparsed-файлы (если они здесь виноваты) окончательно меня зае... достали, потому что:

- Не позволяют просто и прозрачно (т.е. без хитроумных расчетов) планировать использование жесткого диска.

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

chukcha ★★★★★
() автор топика
Последнее исправление: chukcha (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.