LINUX.ORG.RU
решено Форум — Admin  

Нехватка Inode на ext4 разделе

 


1

2

Всем доброго времени суток!

Довольно давно мучаюсь с такой проблемой: на одном небольшом сервере постоянно нехватает inode: 

# df -i     
Файловая система Iнодов IИспользовано IСвободно IИспользовано% Cмонтировано в
/dev/root          1,2M          1,2M         1           100% /
/dev/sda2          1,2M           57K      1,2M             5% /home
/dev/sdb1          1,2M          199K      994K            17% /usr
tmpfs               60K             1       60K             1% /dev/shm
# df
Файловая система Размер Использовано  Дост Использовано% Cмонтировано в
/dev/root           19G         5,6G   13G           30% /
/dev/sda2           19G          18G  893M           96% /home
/dev/sdb1           19G         5,4G   13G           31% /usr
tmpfs              239M            0  239M            0% /dev/shm
Стоит удалить несколько файлов где-нибудь, как через полчаса опять всё забито.

Как определить где создаются файлы и/или какой процесс их создаёт?

find / -type f -mmin 10 уже пробовал. Её выполнение занимает больше времени, чем исчезновение свободного места на диске.

Система: Slackware-current x86
В системе полно самописных скриптов, но отключить их все проблематично.

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

★★★★★
← /var/log/ — не меняются права chown
luks + неразмеченная область на диске. →

На сервере работает только NAT и Apache для статистики. И несколько маленьких скриптов, делающих разные мелкие дела, типа представления статистики в удобном виде.

До недавнего времени там был ещё squid, но с исчезновением места он перестал работать, хотя его кеш я перекинул на /home/

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

Свежий du вроде имеет ключ -i

в coreutils-8.21 не имеет.

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

Я бы начал с выноса /tmp & /var на отдельные разделы.

Запусти iotop/atop посмотри кто активно пишет.

vel ★★★★★
()
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от ii343hbka

И всё-таки, проблема оказалась родственной.

Не это: http://habrahabr.ru/post/152193/

Но решение пригодилось: http://greendail.ru/node/388

Хотя у меня и не FreeBSD. И я ещё не понял, что к чему, но поиск в указанном направлении вывел на решение. Спасибо!

Ещё немного и я разберусь что создаёт эму тучу файлов.

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

На дворе 2014 год, а в extfs до сих пор приходится вручную выделять inodes.

Лучше уж пользоваться протухшей, насквозь ынтырпрайзной jfs.

fat_angel ★★★★★
()

все данные заныкать переформатировать раздел mkfs.ext4 -i 2048 /dev/sdaX потом вернуть все назад

anonymous
()

Файловая система Iнодов
/dev/root 1,2M

ССЗБ

Deleted
()
Ответ на: комментарий от fat_angel

Лучше уж пользоваться протухшей, насквозь ынтырпрайзной jfs.

кто тебе запрещает?

emulek ★
()

Как определить где создаются файлы и/или какой процесс их создаёт?

сначала iostat покажет девайс, потом lsof покажет файлы. Тебе нужен каталог который постоянно долбится.

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

почтовик флудит?

Похоже, что да. Точнее, что-то флудит для почтовика, которого как раз нет, чтобы разгрести всё это.

ССЗБ

fargred, ну, знаешь, после очистки /var/spool/clientmqueue Занято всего 3%. Мне хватит.

fractaler ★★★★★
() автор топика
Последнее исправление: fractaler (всего исправлений: 1)
Ответ на: комментарий от fat_angel

На дворе 2014 год, а в extfs до сих пор приходится вручную выделять inodes.

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

(как будто если установил BTRFS то значит надо обязательно использовать все BTRFS-фишки)

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

Похоже, что да. Точнее, что-то флудит для почтовика, которого как раз нет, чтобы разгрести всё это.

обычно это что-то в crontab, с ошибкой. А почтовик не настроен. Вот и получается 100500 мелких файлов с ошибкой.

покажи 

# find / -type d -printf "%T@ %s %p\n" | sort -n | tail
emulek ★
()
Ответ на: комментарий от Deleted

3% от 1,2 млн. инодов это 36000. У тебя 36000 файлов в корне?

Интересное наблюдение. Наверное да. Если учесть, что на отдельный раздел вынесены только /home и /usr, то это даже не кажется мне странным.

На очень похожем серваке с чуть большим количеством функций и не вынесенным отдельно /usr после очистки /var/spool/clientmqueue занято 26% inode. Пока это количество не растёт и не грозит нарушить функциональность сервера, оно как-то не вызывает беспокойства. А должно?

emulek: 

# find / -type d -printf "%T@ %s %p\n" | sort -n | tail
1392531556.3920600090 0 /proc/27922/net/rpc/nfs4.idtoname
1392531556.3920600090 0 /proc/27922/net/rpc/nfs4.nametoid
1392531556.3920600090 0 /proc/27922/net/rpc/nfsd.export
1392531556.3920600090 0 /proc/27922/net/rpc/nfsd.fh
1392531556.3920600090 0 /proc/27922/net/stat
1392531556.3920600090 0 /proc/27922/task/27922
1392531556.3920600090 0 /proc/27922/task/27922/attr
1392531556.3920600090 0 /proc/27922/task/27922/fd
1392531556.3920600090 0 /proc/27922/task/27922/fdinfo
1392531556.3920600090 0 /proc/27922/task/27922/ns

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

Интересное наблюдение. Наверное да. Если учесть, что на отдельный раздел вынесены только /home и /usr, то это даже не кажется мне странным.

надо ещё /var/ отдельно делать. Или форматировать корень с опцией

-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.

дефолт записан в /etc/mke2fs.conf, у меня 

[defaults]
	base_features = sparse_super,filetype,resize_inode,dir_index,ext_attr
	default_mntopts = acl,user_xattr
	enable_periodic_fsck = 0
	blocksize = 4096
	inode_size = 256
	inode_ratio = 16384

т.е. у меня один инод на 16К Это значение обычно подходит, но если ты создаёшь файлы <16K в большом количестве — увы.

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

инкриментирую. у нас сессии как то на диск начали писаться вместо мемкеша.

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

БД locate обновляется реже, чем пхп штампует сессии.

Lavos ★★★★★
()
Ответ на: комментарий от emulek 
# find / -type d ! -path "/proc/*" ! -path "/sys/*" -printf "%T@ %s %p\n" | sort -n | tail
1392878474.7669650810 160 /dev/.udev
1392879601.8569745030 4096 /home/www/lightsquid/report
1392879696.0049752900 5240 /dev/.udev/db
1392879696.0049752900 640 /dev/.udev/watch
1392879697.7399753040 4096 /etc/webmin/system-status
1392879697.7399753040 4096 /etc/webmin/system-status/history
1392879960.6459775030 4096 /root
1392879961.6399775100 4096 /home/www/gw
1392879976.6409776400 4096 /var/spool/cron/cron.8R6laF
1392879976.8889776380 41385984 /var/spool/clientmqueue

Это значение обычно подходит, но если ты создаёшь файлы <16K в большом количестве — увы.

Стоп-стоп! Это не я, а автоматика создаёт файлы. Проблема уже решена автоматическим удалением этих файлов.

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

БД locate обновляется реже, чем пхп штампует сессии.

Lavos, во-первых, я обновил БД перед командой. Во-вторых, никаких php сессий у меня и нет. Файлы создаются в /var/spool/clientmqueue

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

попробуй это rus-linux.net/MyLDP/kernel/Inotify-tools.html

О! как просто оказывается было отследить! Пока я разобрался, что забивается именно /vat/spool/clientmqueue я порядком замучился.

Хотя, возможно, что оно бы и зависло. Сейчас-то всё чисто.

Ну, да не так важно, этот метод мне наверняка ещё не раз пригодится. Так что спасибо!

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

Стоп-стоп! Это не я, а автоматика создаёт файлы. Проблема уже решена автоматическим удалением этих файлов.

это онанизм. Вот решение: http://www.bsdportal.ru/viewtopic.php?t=13812

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

видимо, как я с самого начала и предполагал, это crond пишет почту. Но т.к. sendmail вы не поставили(не настроили), то отправлять почту некому и некуда. Вот она и копится в очереди на отправку.

Вот смотрите: 

1392879976.6409776400 4096 /var/spool/cron/cron.8R6laF
1392879976.8889776380 41385984 /var/spool/clientmqueue
в 1392879976 секунд появилась задача в спуле кронда, а через 200мс у вас появилась почта. Кстати, там обычный текстовый файл, который можно найти командой

ls -ltr /var/spool/clientmqueue/ | tail -1

рекомендую почитать, там написано КТО пишет, и В ЧЁМ проблема.

А вы лечите головную боль путём регулярного отрубания головы.

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

О! как просто оказывается было отследить!

это не так просто, как вам кажется: inotify это сторожевая собака, которая висит на файле, и гавкает, когда что-то происходит. Проблема в том, что каталог — файл. Т.е. на него можно повесить собаку, она будет гавкать, но только тогда, когда что-то ТАМ изменяется. Если повесить собаку на /var, она НЕ будет гавкать при изменении /var/spool, а тем более /var/spool/clientmqueue как у вас. А развешивать собак НА ВСЕ каталоги... Мне кажется find более рациональный подход.

В данном случае конечно. В общем случае inotify must have.

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

А вы лечите головную боль путём регулярного отрубания головы.

Ну да, я поленился копаться. Однако:

рекомендую почитать, там написано КТО пишет, и В ЧЁМ проблема.

# cat  /var/spool/clientmqueue/qfs1K81GcW017126 
V8
T1392883276
K1392883276
N1
P30154
MDeferred: Connection refused by [127.0.0.1]
Fbs
$_root@localhost
${daemon_flags}c u
Sroot
Aroot@gw44.lan
MDeferred: Connection refused by [127.0.0.1]
C:root
rRFC822; root@gw44.lan
RPFD:root
H?P?Return-Path: <�g>
H??Received: (from root@localhost)
        by gw44.lan (8.14.5/8.14.5/Submit) id s1K81GcW017126;
        Thu, 20 Feb 2014 12:01:16 +0400
H?D?Date: Thu, 20 Feb 2014 12:01:16 +0400
H?F?From: root
H?M?Message-Id: <201402200801.s1K81GcW017126@gw44.lan>
H??To: root
H??Subject: cron for user root /home/scripts/checksquid.sh 1> /dev/null
.

Да, cron. Но о чём? Может, я невнимателен. Но он что, про каждое срабатывание пишет? Тогда как отключить?

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

Мне кажется find более рациональный подход.

find, как и ls зависал при попытке обратиться к каталогу. Возможно, inotifywait тоже бы завис. Сейчас уже как-то не хочется проверять.

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

H??Subject: cron for user root /home/scripts/checksquid.sh 1> /dev/null

что вам непонятно? Какой-то скрипт криво срабатывает (обычно crond пишет почту если код ошибке ≠0).

Тогда как отключить?

проблема здесь: /home/scripts/checksquid.sh

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

find, как и ls зависал при попытке обратиться к каталогу.

они не зависают, а просто долго работают. Причём find работает намного быстрее, ибо НЕ сортирует список. А ls без опции -U — сортирует. Список у вас огромный, т.ч. работает оно медленно. Ещё и удалять будет неделю(я не шучу!). Кстати удалять тоже быстрее всего find /dir/ -delete (только не ошибитесь)

Возможно, inotifywait тоже бы завис

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

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

проблема здесь: /home/scripts/checksquid.sh

Ну, скрипт-то как раз честно выполняет свою работу. Хотя вы уже заставили меня сомневаться. Может, вывод скрипта не всегда идет в /dev/null, а может, иногда, он и вправду не корректно отрабатывает.

Ещё и удалять будет неделю(я не шучу!).

Не сомневаюсь. Я пользовался низкоуровневым способом по ссылкам выше. Удалялось по тысяче с небольшим файлов в минуту. Удалялось около суток.

Ещё раз большое спасибо за помощь! Я узнал много нового и решил проблему.

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

Ну, скрипт-то как раз честно выполняет свою работу. Хотя вы уже заставили меня сомневаться. Может, вывод скрипта не всегда идет в /dev/null, а может, иногда, он и вправду не корректно отрабатывает.

конечно не всегда, ибо ты только первый поток отправил. Надо так:

/path/script.sh >>/var/log/script.log 2>&1

а когда разберёшься с проблемой, то смени >>/var/log/script.log на >/dev/null

Я пользовался низкоуровневым способом по ссылкам выше. Удалялось по тысяче с небольшим файлов в минуту. Удалялось около суток.

это ты про find /dir -delete? На SSD лучше удалять порциями несколько раз, что-бы прошла сборка мусора. Так получается быстрее. (предполагается, что trim работает).

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

конечно не всегда, ибо ты только первый поток отправил. Надо так:
/path/script.sh >>/var/log/script.log 2>&1

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

это ты про find /dir -delete?

Нет, это про http://habrahabr.ru/post/152193/ там небольшая программка на С, которая даже не считывает список всех файлов в каталоге.

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

Нет, это про http://habrahabr.ru/post/152193/ там небольшая программка на С, которая даже не считывает список всех файлов в каталоге.

ну хабра, такая хабра... Ты разве не заметил некоторую разницу с моей командой find /dir -delete, нет? Она работает примерно как и программа хабровца, т.е. вовсе не читает список, а просто его обходит, НЕ преобразуя его весь в текст. Это получится даже быстрее данного костыля ИМХО. Проблема в том, что каталог всё равно надо читать в память, а потом писать его обратно.

emulek ★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← /var/log/ — не меняются права chown
Admin
luks + неразмеченная область на диске. →