[РЕШЕНО] "На устройстве закончилось место", но место ещё есть

[yura3d]

Здравствуйте!
Есть сервер, который работает под управлением Debian 7, аптайм уже почти год.
На сервере есть PHP-скрипт, который запускается по крону и скачивает из Интернета определённые картинки. В последнее время в логах стали изредка проскакивать такие ошибки:

Код Выделить Развернуть

PHP Warning:  imagejpeg(): Unable to open '/home/<...>/photos/1d1fa0efd91aa5eae8e4f9c2d7bc29ff_1.jpg' for writing: На устройстве кончилось место in /home/<...>/parser.php on line 236

Функция PHP imagejpeg() используется для сохранения обработанной скриптом картинки. Как видно из лога, ей не удаётся открыть файл для записи.

Свободное место на разделе есть:

Код Выделить Развернуть

df
Файловая система                                       1K-блоков Использовано  Доступно Использовано% Cмонтировано в
rootfs                                                  48061320     17281660  28338240           38% /
udev                                                       10240            0     10240            0% /dev
tmpfs                                                    3298632          252   3298380            1% /run
/dev/disk/by-uuid/027cdb93-855b-464d-8b4c-b3aab7450c05  48061320     17281664  28338236           38% /
tmpfs                                                       5120            0      5120            0% /run/lock
tmpfs                                                    8159460            0   8159460            0% /run/shm
/dev/sda3                                              905143328    459956668 399208036           54% /home


Ах да, в папке с картинками о-о-о-очень много файлов. Но свободные иноды у раздела есть:

Код Выделить Развернуть

df -i
Файловая система                                         Iнодов IИспользовано IСвободно IИспользовано% Cмонтировано в
rootfs                                                  3055616        135004   2920612             5% /
udev                                                    4121801           355   4121446             1% /dev
tmpfs                                                   4123290           284   4123006             1% /run
/dev/disk/by-uuid/027cdb93-855b-464d-8b4c-b3aab7450c05  3055616        135004   2920612             5% /
tmpfs                                                   4123290             2   4123288             1% /run/lock
tmpfs                                                   4123290             2   4123288             1% /run/shm
/dev/sda3                                              57475072       7903194  49571878            14% /home


Такое происходит очень редко, в остальных 999 случаев из 1000 картинка нормально сохраняется. Подскажите, пожалуйста, куда копать?

[yura_n]

Файловую систему проверяли?

[yura3d]

Файловую систему проверяли?

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

[yura3d]

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

Здравствуйте. Вроде бы появилась информация по возникшей ситуации. fsck ошибок не нашёл, зато я заметил, что в syslog при каждой ошибочной операции создания файла появляется такая запись:

Код Выделить Развернуть

kernel: [26787.684771] EXT4-fs warning (device sda3): ext4_dx_add_entry:1548: Directory index full!
Насколько я понял, проблема в том, что файлов в папке очень много. Где-то мне писали, что у ext4 есть ограничение на 31998 файлов в одной папке. Правда ли это? Получается, единственным решением проблемы будет так переписать скрипт, чтобы он сохранял картинки в разные папки (например, группировал их по дате создания) ?

[endru]

Насколько я понял, проблема в том, что файлов в папке очень много. Где-то мне писали, что у ext4 есть ограничение на 31998 файлов в одной папке.

нагло врут! проверил у себя:

Код Выделить Развернуть

ls -l /srv/samba/shared/small_pic/ | wc -l
43622

в ext3 было ограничение: "для каталога нельзя создать более 32000 подкаталогов"

[qupl]

Поднято ограничение на число вложенных каталогов. ext3 (без использования патчей) позволяла размещать в одном каталоге не более 32 000 подкаталогов (до 65 535, если изменить константы ядра).

[yura3d]

нагло врут! проверил у себя:

Спасибо за информацию. У меня вообще при запуске такого подсчёта ls просто виснет и всё. Сейчас не стал её килять, может за час-другой чего-нибудь и насчитает.
Не могу понять, или там действительно так много файлов, или есть какие-то ошибки.
Гугление на тему "ext4 directory index full" ничего не дало, кроме того, что такие ошибки встречаются и люди о них пишут. Решений (кроме советов не хранить много файлов в одной папке) нет.

Есть ещё вопрос. Хочу снова проверить раздел, но сервер уже отправил в дата-центр, а проблемная папка как раз хранится на разделе с точкой монтирования /home, который просто так отмонтировать нельзя. Доступ к серверу сейчас есть только по SSH. Есть ли какая-нибудь возможность как-то загрузить систему без монтирования /home? Например, перезагрузиться в single user mode (какая команда?) или закомментировать этот раздел в fstab (не будет ли в таком случае ошибок при загрузке ОС из-за отсутствия /home?)

=== (Отредактировано) ===
ls насчитало-таки за 20 минут 7768184 файлов.

[ogost]

при таком количестве файлов в одной папке стандартные утилиты командной строки, например, ls, rm, mv, cp и прочие, начинают тупить. выход - использовать например find с ключом -exec, -delete. у этого способа есть и свои недостатки. есть так же другие способы, они легко гуглятся.
и да, не нужно хранить слишком много файлов в одной папке, редактируйте свой скрипт.


lsof /home покажет какие процессы работают с данным разделом. прибивайте их по мере надобности, и отмонтируйте /home.

[yura3d]

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

Спасибо. Хотелось бы конечно этого избежать, но видимо придётся переписывать скрипт. А вместе с ним и полсайта. Эх..

lsof /home покажет какие процессы работают с данным разделом. прибивайте их по мере надобности, и отмонтируйте /home.

Именно так и делал, убил оставшиеся процессы, диск отмонтировался, но fsck всё равно ругался, что device is busy. Так и не понял в чём причина.

[yura3d]

Спасибо всем, кто откликнулся! Проблема решилась.
Опытным путём было установлено, что после достижения ~7 800 000 файлов в одной папке начинались вышеописанные проблемы.
Помогла чистка неактуальных файлов, снизив их число где-то до 2 000 000, и ошибки пропали.
Но чтобы дальше не жить в ожидании очередного переполнения, да и всё равно 2 ляма файлов в одной папке многовато, переписал-таки скрипт, чтобы файлы сохранялись в разных папках. Что интересно, сохранение стало работать гораздо быстрее.