ext4: изменение размера в сети не обнаружено

На сервере RedHat 6 мы столкнулись с проблемой онлайн-изменения размера файловой системы ext4.

Только с /dev/sda у нас было 13 ГБ в группе томов, но на один логический том, который был 36 ГБ, требовалось еще 20 ГБ. Добавил / dev / sdb в группу томов, и файловая система была расширена (lvextend) и изменена в размере (resize2fs) до 56 ГБ. Нет сообщений об ошибках во время изменения размера, и ОС сообщила о новом размере.

Рассматриваемый логический том содержит установку IBM HTTP Server (apache 2.2), файлы конфигурации и журналов для примерно 8 различных веб-серверов.

Сегодня утром использование файловой системы превысило 36 ГБ. Сначала произошло то, что веб-серверы перестали регистрироваться (обнаружены после), в то время как веб-серверы продолжали работать без проблем. Спустя 2,5 часа, в связи с ротацией журналов и некоторыми другими записями в файловой системе, все стало зависать. Значение: веб-серверы прекратили принимать трафик, хотя процессы не работали, попытка "привязать" файл журнала зависала и не могла быть прервана. Загрузка сервера изменилась с 0.10 до 4000 (да...) - в основном это связано с iowait (казалось бы).

Решение состояло в том, чтобы выключить веб-сервер - единственный способ убить -9 и перезагрузить сервер. Размонтируйте файловую систему, выполните команду fsck (без ошибок) и запустите все заново. Никаких проблем с тех пор.

Мы можем точно определить время, когда ошибка остановилась, когда время использования диска (lv) превысило прежний размер в 36 ГБ.

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

В /var/log/messages мы видели то есть:

kernel: INFO: task httpd:<pid> blocked for more than 120 seconds.
kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kernel: httpd         D 0000000000000001     0  6889   6865 0x00000080
kernel: ffff88023aa99c88 0000000000000086 0000000000000000 0000000000006102
kernel: ffff88010aebaa80 ffff880105dd0ae0 000000003aa99c08 ffff880105dd0ae0
kernel: ffff880105dd1098 ffff88023aa99fd8 000000000000fb88 ffff880105dd1098
kernel: Call Trace:
kernel: [<ffffffff8150efbe>] __mutex_lock_slowpath+0x13e/0x180
kernel: [<ffffffff8150ee5b>] mutex_lock+0x2b/0x50
kernel: [<ffffffff8111c461>] generic_file_aio_write+0x71/0x100
kernel: [<ffffffffa0097fb1>] ext4_file_write+0x61/0x1e0 [ext4]
kernel: [<ffffffff81180d7a>] do_sync_write+0xfa/0x140
kernel: [<ffffffff81096ca0>] ? autoremove_wake_function+0x0/0x40
kernel: [<ffffffff8121bc06>] ? security_file_permission+0x16/0x20
kernel: [<ffffffff81181078>] vfs_write+0xb8/0x1a0
kernel: [<ffffffff81181971>] sys_write+0x51/0x90
kernel: [<ffffffff810dc645>] ? __audit_syscall_exit+0x265/0x290
kernel: [<ffffffff8100b072>] system_call_fastpath+0x16/0x1b

Версии:

Kernel: 2.6.32-358.2.1.el6.x86_64
lvm2-2.02.98-9.el6.x86_64
e2fsprogs-1.41.12-14.el6.x86_64

Не было найдено проблем с базовым оборудованием.

1 ответ

Решение

Ответ: файловая система была создана с mke2fs <device>

Поведение по умолчанию заключается в создании файловой системы ext2. Однако он был смонтирован как файловая система ext4 - без каких-либо сообщений об ошибках - и позднее воспринимался как файловая система ext4.

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

Потребовалось некоторое время, чтобы обнаружить, поскольку между созданием и изменением размера прошло много времени, и он был наконец обнаружен при запуске blkid, который сказал "ext2". tune2fs -l также сказал "не чисто".

Другие вопросы по тегам