URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 91835
[ Назад ]

Исходное сообщение
"Проблемы с файловой системой"

Отправлено ksudak , 27-Июн-11 10:09 
Вывод команды "df -h"

[root@srv]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/simfs             44G   12G     0 100% /
none                  2.4G  4.0K  2.4G   1% /dev

Товарищи помогите, как такое вообще возможно, и как это вылечить ?
что это за бред - ( /dev/simfs             44G   12G     0 100% / )


Содержание

Сообщения в этом обсуждении
"Проблемы с файловой системой"
Отправлено PavelR , 27-Июн-11 10:49 
Если я правильно понимаю, то это OpenVZ.
Может вам в саппорт хостера обратиться? Там всё разъяснят...

"Проблемы с файловой системой"
Отправлено ksudak , 27-Июн-11 10:55 
> Если я правильно понимаю, то это OpenVZ.
> Может вам в саппорт хостера обратиться? Там всё разъяснят...

Да, вы правильно думаете, сорри что забыл написать что это виртуальная машина на OpenVZ.
Только вот хостер я сам себе, так как сервак c OpenVZ мне принадлежит.
А что это за проблема, куда глядеть?


"Проблемы с файловой системой"
Отправлено DeadLoco , 27-Июн-11 11:05 
> А что это за проблема, куда глядеть?

А не хранятся ли на этой ФС логи апача? Чаще всего такое случается из-за ротации логов апача. Newsyslog логи ротирует, а апач не понимает, что старый файл нужно закрыть и открыть на запись новый. При этом дф занятое место считает "по головам" - по именам файлов, а апач через дескриптор обращается к иноде, у которой имени может и не быть.

Запускать lsof и внимательно смотреть, что кем открыто.


"Проблемы с файловой системой"
Отправлено ksudak , 27-Июн-11 11:30 
>> А что это за проблема, куда глядеть?
> А не хранятся ли на этой ФС логи апача? Чаще всего такое
> случается из-за ротации логов апача. Newsyslog логи ротирует, а апач не
> понимает, что старый файл нужно закрыть и открыть на запись новый.
> При этом дф занятое место считает "по головам" - по именам
> файлов, а апач через дескриптор обращается к иноде, у которой имени
> может и не быть.
> Запускать lsof и внимательно смотреть, что кем открыто.

Логи все я потёр, да их и не много было. Дело то в вот в чём:
                      Size  Used Avail Use% Mounted on
/dev/simfs             44G   12G     0 100% /

Использовано 12G, а где остальные 32G ?


"Проблемы с файловой системой"
Отправлено ksudak , 27-Июн-11 11:32 
>[оверквотинг удален]
>> Запускать lsof и внимательно смотреть, что кем открыто.
> Логи все я потёр, да их и не много было. Дело то
> в вот в чём:
>            
>           Size
>  Used Avail Use% Mounted on
> /dev/simfs            
>  44G   12G     0 100%
> /
> Использовано 12G, а где остальные 32G ?

Кажись PavelIR правильно подметил ковырять надо OpenVZ, другое дело что именно?


"Проблемы с файловой системой"
Отправлено DeadLoco , 27-Июн-11 11:52 
> Использовано 12G, а где остальные 32G ?

Попробую еще раз, только набирать буду медленно и максимально популярно.

Команда df использованое место подсчитывает по сумме размеров всех файлов с именами. Если у файла нет имени, его размер в итог не попадет. Да, у файла может не быть имени, потому что имя - это только запись в каталоге, а софты работают с файлами через файловые дескрипторы, обращающиеся к инодам - элементам структуры ФС. При этом df свободное место определяет по количеству неиспользованых инодов.

Открываем файл на запись. В каталоге находится нужное имя, считывается номер первого инода этого файла и вешается на файловый дескриптор. По мере записи из ФС выделяются дополнительные иноды, которые паровозиком выстраиваются в цепочку один за другим.

Если теперь "удалить файл" командой rm, то удалится не сам файл, а только его имя в каталоге. Цепочка инодов зависнет неудаленной без имени, удерживаемая файловым дескриптором, через который идет запись. Имени у цепочки инодов нет - в сумму занятого места эта цепочка не попадет. Иноды цепочки не числятся в свободных - значит в свободное место на ФС они тоже не войдут. При этом занято мало, а свободного места нет.

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


"Проблемы с файловой системой"
Отправлено ksudak , 27-Июн-11 12:40 
>[оверквотинг удален]
> Если теперь "удалить файл" командой rm, то удалится не сам файл, а
> только его имя в каталоге. Цепочка инодов зависнет неудаленной без имени,
> удерживаемая файловым дескриптором, через который идет запись. Имени у цепочки инодов
> нет - в сумму занятого места эта цепочка не попадет. Иноды
> цепочки не числятся в свободных - значит в свободное место на
> ФС они тоже не войдут. При этом занято мало, а свободного
> места нет.
> Чаще всего такое происходит при ротации логов апача, у апача логирование не
> вполне тривиально. Во всех остальных случаях - при ротации других логов.
> Софт пишет в файл, файл удаляется или перемещается - вуаля.

Спасибо, принцип понял. Только как быть в такой ситуации?
Отключить ротацию логов апача, или выполнить fsck ?


"Проблемы с файловой системой"
Отправлено DeadLoco , 27-Июн-11 12:54 
> Спасибо, принцип понял. Только как быть в такой ситуации?
> Отключить ротацию логов апача, или выполнить fsck ?

Сначала нужно найти - кто из софтов держит "удаленный" файл. Для этого есть утилита lsof, которая как раз и показывает файлы, открытые разными процессами. Читаете ман, изучаете открытые файлы, много думаете.

Если вы сейчас перегрузите машину и прогоните fsck, то у вас дескриптор отпустит иноду, а fsck затопчет все следы. В результате вам придется ждать еще сколько-то времени, прежде чем опять образуется та же ситуация. Поэтому, пока болячка налицо, нужно искать причину. Как найдете - кто, тогда и решение можно будет искать.


"Проблемы с файловой системой"
Отправлено PavelR , 27-Июн-11 12:59 
>> Спасибо, принцип понял. Только как быть в такой ситуации?
>> Отключить ротацию логов апача, или выполнить fsck ?
> Сначала нужно найти - кто из софтов держит "удаленный" файл. Для этого
> есть утилита lsof, которая как раз и показывает файлы, открытые разными
> процессами. Читаете ман, изучаете открытые файлы, много думаете.
> Если вы сейчас перегрузите машину и прогоните fsck, то у вас дескриптор
> отпустит иноду, а fsck затопчет все следы. В результате вам придется
> ждать еще сколько-то времени, прежде чем опять образуется та же ситуация.
> Поэтому, пока болячка налицо, нужно искать причину. Как найдете - кто,
> тогда и решение можно будет искать.

А что, на этой фс можно прогнать fsck ?


:-)))


"Проблемы с файловой системой"
Отправлено ksudak , 27-Июн-11 13:08 
>[оверквотинг удален]
>> Сначала нужно найти - кто из софтов держит "удаленный" файл. Для этого
>> есть утилита lsof, которая как раз и показывает файлы, открытые разными
>> процессами. Читаете ман, изучаете открытые файлы, много думаете.
>> Если вы сейчас перегрузите машину и прогоните fsck, то у вас дескриптор
>> отпустит иноду, а fsck затопчет все следы. В результате вам придется
>> ждать еще сколько-то времени, прежде чем опять образуется та же ситуация.
>> Поэтому, пока болячка налицо, нужно искать причину. Как найдете - кто,
>> тогда и решение можно будет искать.
> А что, на этой фс можно прогнать fsck ?
> :-)))

только вот тут же видно что inode полно свободных:

[root@srv]# df -i
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/simfs           6862404   93306 6769098    2% /
none                  611093      95  610998    1% /dev


"Проблемы с файловой системой"
Отправлено DeadLoco , 27-Июн-11 13:14 
> А что, на этой фс можно прогнать fsck ?
> :-)))

Без понятия, я с openVZ дела никогда не имел.


"Проблемы с файловой системой"
Отправлено ksudak , 28-Июн-11 11:55 
>> А что, на этой фс можно прогнать fsck ?
>> :-)))
> Без понятия, я с openVZ дела никогда не имел.

ПРОБЛЕМА РЕШЕНА !!!
Это был глюк MySQL на одном из виртуальных серверов, он почему-то под временные таблицы забрал всю память HDD, я перезапустил сервис MySQL и все стало ок.
На OpenVZ такие случаи - постоянные, хотя железно выделили им место в конфигах, а они вылазят за них, и глюк какой-то с MySQL странный вообще сожрал всё место на своей виртуалке, вылез за пределы и сожрал место на всей хост-машине OpenVZ, а потом и у всех остальных её виртуальных серверов. В общем жесть, вот вам недостаток паравиртуализации!
Всех благодарю за ответы ;)