Закончились иноды в /var

man mke2fs

какую ФС лучше всего взять на замену для /var

Для тебя — ntfs.

Для тебя — ntfs

Осталось найти нормальные драйвера под неё.

ЕМНИП рейзер создает иноды по мере необходимости. i-rinat, поправь, если я не прав.

Каким г^Wобразом ты забил /var ?

Иноды используются для файлов. Число использованных inode должно совпадать с числом всех файлов ( включая директории, ссылки, файлы устройств, каналы и т.п. )

router@amalthea:~$ find /var/ -type d -exec find {} ! -type d -mindepth 1 -maxdepth 1 | wc -l \;
find: wc: отсутствует аргумент у `-exec'
;: Нет такого файла или каталога

Идея понятна? Второй вызов find вместе с каналом сделай в виде отдельного скрипта, мне сейчас некогда

Сделал tree /var>>var.txt и беглым просмотром обнаружил каталог /var/spool/exim4/input, засранный 42384 файлами с именами типа 1Rvs5t-00052Q-Uv-H, в которых каждые полчаса крон бодро рапортовал об очистке каталогов с сессиями PHP (кстати, как это оповещение отключить?). Судя по всему иноды закончились ещё где-то 7 марта, т.к. более новых файлов нет. Сделал tar cpjf input.tar.bz2 /var/spool/exim4/input для дальнейшего изучения и rm -f /var/spool/exim4/input/*. Стало лучше:

# df -i /var
Файлова система       Inodes   IUsed   IFree IUse% змонтований на
/dev/sda5              65808   23439   42369   36% /var

Закончились иноды в /var (комментарий)

man mke2fs

Или используй XFS.

Или используй XFS.

Оно же вроде для мелких файлов не очень?

Да нормально. Хотя по сравнению с ext4 не очень. Ну тогда читай указанный ман, там написано как определить число inode при создании ФС.

рейзер создает иноды по мере необходимости

там нет инодов. Место под то, что в ext4 хранится в инодах, выделяется динамически. Но там свои странности. Лучше пересоздать ext4 с большим числом инодов.

ФС в студию.

обнаружил каталог /var/spool/exim4/input, засранный 42384 файлами

Вопрос почему у тебя почта не уходит и письма валяются в очереди exim'a?

отменять отправку писем cron'ом, в данном случае — костыль.

ФС в студию

ext4 же, в тегах есть.

Вопрос почему у тебя почта не уходит и письма валяются в очереди exim'a?

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

отменять отправку писем cron'ом, в данном случае — костыль.

Просто не вижу смысла каждые полчаса рапортовать об очистке каталога.

Сделал tree /var>>var.txt и беглым просмотром обнаружил каталог /var/spool/exim4/input, засранный 42384 файлами

я не понял, а что var такой маленький, и почему ты, одмин, почту не читаешь? Сделай var побольше, а если не хочешь читать почту - отключи (как - не помню, искать лень. Как в твоём php-скрипте - даже не знаю).

Но о смене ФС для /var всё равно задумываюсь.

ктож под /var так мало инодов выделяет-то??? У меня вот десктоп без всяких серверов:

# find /var | wc -l
32395

      -i bytes-per-inode
              Specify the bytes/inode ratio.  mke2fs creates an inode for every bytes-per-inode bytes of space on the disk.  The
              larger the bytes-per-inode ratio, the fewer inodes will be created.  This value  generally  shouldn't  be  smaller
              than  the  blocksize  of  the  filesystem, since in that case more inodes would be made than can ever be used.  Be
              warned that it is not possible to expand the number of inodes on a filesystem after it is created, so  be  careful
              deciding the correct value for this parameter.

ЗЫЖ ИМХО ext4 - самая лучшая для хранения БОЛЬШОГО числа мелких файлов, особенно в одном каталоге. Всё остальное - глючное и тормозное говно.

а что var такой маленький

А зачем больше? Если не считать срача с почтой, скопившегося за пару лет, его вполне хватает:

# df -h /var
Файлова система       Size  Used Avail Use% змонтований на
/dev/sda5            1012M  281M  680M  30% /var

и почему ты, одмин, почту не читаешь?

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

а если не хочешь читать почту - отключи

Уже сделал, см. Отключить отправку писем при выполнении заданий крона

ктож под /var так мало инодов выделяет-то???

Я просто оставил дефолт, не думая что с этим возникнут какие-то грабли.

А зачем больше? Если не считать срача с почтой, скопившегося за пару лет, его вполне хватает:

мог бы и пару лет назад спросить у меня, я-бы тебе ещё тогда сказал, что мало. Либо почту пилить/читать/следить надо, либо больше инодов делать.

Не вижу смысла читать об очистке каталога каждые полчаса (кто же её столько будет читать-то?).

аффтор php-скрипта наверное. Я откуда знаю, кто шлёт?

Уже сделал, см. Отключить отправку писем при выполнении заданий крона

мой ответ см. там же

Я просто оставил дефолт, не думая что с этим возникнут какие-то грабли.

ну… на ошибках учатся.

мог бы и пару лет назад спросить у меня, я-бы тебе ещё тогда сказал, что мало. Либо почту пилить/читать/следить надо, либо больше инодов делать.

Вообще их хватает. Причина возникшего срача — костыльная изкоробочная конфигурация для автоочистки файлов PHP-сессий в дебиане.

аффтор php-скрипта наверное. Я откуда знаю, кто шлёт?

PHP-скрипты там вообще не при чём. Ты же отвечал на моё сообщение, в котором это было написано:

крон бодро рапортовал об очистке каталогов с сессиями PHP

Вообще их хватает.

для var не хватает. Почта бывает и от других ошибок.

Ты же отвечал на моё сообщение, в котором это было написано: «крон бодро рапортовал об очистке каталогов с сессиями PHP»

crond рапортовал об ОШИБКЕ, потому-что юниксвейно выполнять команду молча, и не жужжать. А если жужжит → ошибка, и её нужно исправить. Надо было раньше почту читать, два года назад, когда сервер подымал.

для var не хватает. Почта бывает и от других ошибок.

Вряд-ли от чего-то другого она будет сыпаться каждые полчаса.

crond рапортовал об ОШИБКЕ

Начинать комментарии с решётки — это уже ошибка. Прямо какое-то соревнование велосипедов „кривой и ещё кривее”.

Вряд-ли от чего-то другого она будет сыпаться каждые полчаса.

было. Я точно даже и не помню, от чего. Тоже накриворучил где-то.

Начинать комментарии с решётки — это уже ошибка. Прямо какое-то соревнование велосипедов „кривой и ещё кривее”.

это PHP, смирись. Или юзай нормальные ЯП.

костыльная изкоробочная конфигурация для автоочистки файлов PHP-сессий в дебиане.

Вот не надо наговаривать. У меня не сыпется же, однако исправно выполняется очистка. Значит ты что-то сам наисправлял.

это PHP, смирись. Или юзай нормальные ЯП.

PHP тут не при чём. Проблема в конфигах, в каждом из которых свой собственный велосипедный формат.

PHP тут не при чём. Проблема в конфигах, в каждом из которых свой собственный велосипедный формат.

научись читать, цитирую твой пост:

PHP Deprecated: Comments starting with '#' are deprecated in /etc/php5/apache2/php.ini

пруфлинк: Отключить отправку писем при выполнении заданий крона (комментарий)

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

Для того, чтобы у меня исправно выполнялась очистка для виртуальных хостов мне пришлось ещё вручную его править, прописывая путь к tmp-каталогам, хотя эти каталоги уже заданы в настройках виртуального хоста. ИМХО это костыль.

Значит ты что-то сам наисправлял

Да, уже разобрался. Использовал # вместо ; для комментариев в /etc/php5/apache2/php.ini.

научись читать

И тебе того же.

PHP Deprecated: Comments starting with '#' are deprecated in /etc/php5/apache2/php.ini

И при чём здесь PHP как ЯП? Совсем слака мозг выела.

«не очень» было пару лет назад. сейчас «очень».

хотя эти каталоги уже заданы в настройках виртуального хоста. ИМХО это костыль.

А как бы ты это сделал?

ну… на ошибках учатся.

Вообще я не считаю это ошибкой. Если бы я сделал /var с бо́льшим количеством инодов — он бы всего лишь засрал его полностью не так быстро, соответственно я бы обнаружил проблему позже, т.к. визуально всё работает. Моей ошибкой было то, что я ориентировался лишь на сообщения в консольке, а не рылся где-то в ебенях системы в поисках „а вдруг что не так”, да.

А как бы ты это сделал?

Проверил бы существование опции php_admin_value session.save_path в /etc/apache2/sites-enabled/* и, если она есть, брал пути оттуда и вычищал. ИМХО такая конфигурация с виртуальными хостами очень даже распространена. Сейчас же по факту приходится прописывать пути дважды.

Проверил бы существование

Что стоит между тобой и реализацией? Хоть бы баг запостил на багтрекер. Если реализация настолько простая, как ты о ней говоришь, наверное и патч можно замутить.

Что стоит между тобой и реализацией?

Нужно тщательно оттестировать и продумать возможные нюансы. Всё же это удаление данных, потенциально рискованная операция.

XXI век на дворе, а люди все еще сношают мозг количеством инодов…

XXI век на дворе, а люди все еще сношают мозг количеством инодов…

drBatty кто-то тут, сравнивая ext* и NTFS, всерьёз называл последнюю морально устаревшей ФС из 80-х годов. Как говорится, в своём глазу бревно невидимо.

И при чём здесь PHP как ЯП? Совсем слака мозг выела.

извиняюсь. Это php выел. И как ЯП дерьмо, и конфиг тоже дерьмо.

Вообще я не считаю это ошибкой. Если бы я сделал /var с бо́льшим количеством инодов — он бы всего лишь засрал его полностью не так быстро, соответственно я бы обнаружил проблему позже, т.к. визуально всё работает.

другая ФС начала-бы просто люто тупить с большим числом файлов в одной «папке». Я проверял.

Моей ошибкой было то, что я ориентировался лишь на сообщения в консольке, а не рылся где-то в ебенях системы в поисках „а вдруг что не так”, да.

как-то ты нехорошо отозвался о почте к администратору, учитывая, что админ - это ты.

кто-то тут, сравнивая ext* и NTFS, всерьёз называл последнюю морально устаревшей ФС из 80-х годов.

так и есть. Попробуй там создать папку с таким количеством файлов. А в EXT4 даже всё работает. Хотя на такой юзкейс, да, требуется ручная настройка или куча места свободного.

Как говорится, в своём глазу бревно невидимо.

ты не знал про inode.

Просто не вижу смысла каждые полчаса рапортовать об очистке каталога.

Если скрипт очищающий сессии в кроне, то всё что он выплюнет на stdout скорее всего будет отправлено в почту.

как-то ты нехорошо отозвался о почте к администратору, учитывая, что админ - это ты.

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

ты не знал про inode.

А можно сразу списочек чего еще нужно знать о внутренностях fs что бы ими пользоваться ?

И кому собственно сдавать экзамен по этим самым внутренностям ?

PS: В 21-м веке иметь дистриб без автоматического увеличения inode, это только в linux такое возможно

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

PS: так что из скриптов сообщения пользователю лучше убрать, чистил, ну или перенаправление в /dev/null

А дефрагментатор, и тот только недавно сделали.

так и есть. Попробуй там создать папку с таким количеством файлов

Там я просто в такую ситуацию не попадал никогда, поэтому даже не знаю зачем это может быть нужно. Сейчас под рукой на NTFS-разделе есть каталог с 9к файлов в нём, не учитывая файлы во вложенных подкаталогах. УМВР.

А в EXT4 даже всё работает

Возможность засрать все иноды и плеваться отсутствием места, когда его ещё больше половины — это великое достижение 21 века в сфере архитектуры ФС, да.

ты не знал про inode.

Знал, именно поэтому сразу же сделал df -i. Я думал что дефолтные параметры адекватны и мне их хватит, поэтому дальше не ковырял.

другая ФС начала-бы просто люто тупить с большим числом файлов в одной «папке». Я проверял

Сделал 50k файлов в одной директории на ext4: 3,0 секунды. Сделал 50k файлов в одной директории на reiserfs: 3,1 секунды. Погрешность измерять лень. Mc заходит в директории с заметной задержкой, но явно меньше секунды.

Очистил кэши, time ls -l > /dev/null на ext4 отрабатывает за 3,5 секунды, на reiserfs — за 1,5 секунды (отклонения порядка +- 0,1 сек). С прогретыми кешами — по 0,7 секунды. Тупить, говоришь?

Сделал tree /var>>var.txt и беглым просмотром обнаружил каталог /var/spool/exim4/input, засранный 42384 файлами с именами типа 1Rvs5t-00052Q-Uv-H

Т.е. ещё и exim криво настроен. Почта в очереди не должна накапливаться. Либо она доставляется, либо отправителю высылается bounce mail о невозможности доставки. А если и bounce не получается доставить, то он молча сбрасывается.

каждые полчаса крон бодро рапортовал об очистке каталогов с сессиями PHP (кстати, как это оповещение отключить?).

man bash. Перенаправь вывод в файл

Ещё плохо то, что в дебиане по умолчанию ничего никуда не перенаправляется, просто торчит вот такой вот скрипт в кроне. Поэтому в случае установки новичком apache+php и правки php.ini для какого-нибудь девелопмента через какое-то время получаем отсутствие инодов в /var (или в /) одновременно с кучей свободного места, засранный в лучшем случае тысячами одинаковых файлов /var/spool/exim4/input с одинаковыми сообщениями и очень удивлённого новичка, не знающего даже в какую сторону копать.

другая ФС начала-бы просто люто тупить с большим числом файлов в одной «папке». Я проверял.

ЛЮТО тупить ??!?! При частоте обращений к данной «папке» один раз в ТРИНДАЦАТЬ МИНУТ ?

Какого только бреда от тебя не прочитаешь. LOL

Т.е. ещё и exim криво настроен

Я его не настраивал вообще, просто отключил демон т.к. он мне ненужен и тормозит систему при загрузке.

тормозит систему при загрузке

хороший у тебя ник. хост в dns забыл внести?

хороший у тебя ник. хост в dns забыл внести?

Чтобы прочитать сообщение об ошибке мне кроме почты нужно ещё и DNS поднимать? Отличное юзерфрендли.