EXT4-fs error (device dm-4): htree_dirblock_to_tree: ...

[yura3d]

Здравствуйте! В стане системных администраторов Debian я не так давно, поэтому задаю вопрос в таком разделе.
На сервере под управлением Debian 6.0 вышел из строя блок питания прямо во время работы сервера (т.е. работа системы завершилась аварийно). После замены блока питания и повторного запуска сервера было обнаружено, что утеряны несколько файлов и повреждены некоторые таблицы в MySQL (очевидно, те, с которыми в момент краха производилась работа). Но эти вопросы уже решены и данные частично восстановлены из резервной копии. Беспокоит же следующее: ежедневно в логах /var/log/kern.log и /var/log/syslog наблюдаю строки:

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

EXT4-fs error (device dm-4): htree_dirblock_to_tree: bad entry in directory #8786418: directory entry across blocks - block=35138535offset=2160(10172528), inode=11008435, rec_len=131120, name_len=38

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

EXT4-fs error (device dm-4): ext4_add_entry: bad entry in directory #8786418: directory entry across blocks - block=35138535offset=2160(2160), inode=11008435, rec_len=131120, name_len=38

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

EXT4-fs error (device dm-4): ext4_dx_find_entry: bad entry in directory #8786418: directory entry across blocks - block=35138535offset=2160(10172528), inode=11008435, rec_len=131120, name_len=38
Эти строки в разных комбинациях пишутся в лог иногда с интервалом в минуту, иногда в час и даже более. Как можно решить проблему? Насколько я понял, имеет место ошибка файловой системы? Сейчас на сервере используется ext4. Поможет ли устранить ошибку fsck и не убьёт ли при этом раздел (какова вообще вероятность повреждения раздела в данном случае)? Стоит ли перед проверкой делать бекап? Можно ли запустить fsck на рабочей системе или это стоит делать только при её запуске (у меня осуществляется проверка разделов при каждой загрузке ОС). С какими параметрами запускать fsck? На данный момент боюсь что-либо предпринимать, даже перезагружать сервер, т.к. его бесперебойная работа очень важна
Заранее благодарю за любую помощь и информацию по вопросу
Сообщение объединено: 24 января 2013, 14:55:11
Да, и чуть не забыл, на сервере сконфигурирован fakeraid через утилиту dmraid.

[qupl]

Вопрос про бэкап странный, его нужно делать всегда.

[yura3d]

Вопрос про бэкап странный, его нужно делать всегда.

Сейчас такая ситуация сложилась, что сайт "разросся" и на сервере уже не хватает свободного места для полного бекапа. Уже задумываюсь прикупить специально для этих целей отдельный жёсткий диск, но его ещё нужно отвезти в дата-центр и там всё это дело подключить, поэтому решение это не быстрое. Ну а пока часть бекапа придётся копировать на свой компьютер по медленному ADSL-соединению. Просто если вероятность убийства раздела через fsck ничтожно мала, то возможно, не стоит мучиться с выкачиванием большого объёма данных по ADSL. Я просто не знаю, насколько серьёзны эти ошибки:

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

EXT4-fs error (device dm-4): htree_dirblock_to_tree: bad entry in directory #8786418: directory entry across blocks - block=35138535offset=2160(10172528), inode=11008435, rec_len=131120, name_len=38

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

EXT4-fs error (device dm-4): ext4_add_entry: bad entry in directory #8786418: directory entry across blocks - block=35138535offset=2160(2160), inode=11008435, rec_len=131120, name_len=38

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

EXT4-fs error (device dm-4): ext4_dx_find_entry: bad entry in directory #8786418: directory entry across blocks - block=35138535offset=2160(10172528), inode=11008435, rec_len=131120, name_len=38

и может ли fsck при их исправлении взять и убить раздел?

[qupl]

yura3d, 100% гарантии никто не даст. Скорее всего просто исправятся ошибки и всё будет нормально. Но рисковать важными данными не стоит.

[yura3d]

yura3d, 100% гарантии никто не даст. Скорее всего просто исправятся ошибки и всё будет нормально. Но рисковать важными данными не стоит.

Сегодня забрал сервер с дата-центра, чтобы окончательно разобраться с возникшей проблемой. Хотелось бы понять, что это за устройство такое, dm-4? Ранее не имел никаких дел с device mapper, полуаппаратным (SATA fake-raid) и программным RAID. Какому реальному диску соответствует dm-4? Дело в том, что в логах ошибки выводятся именно со ссылкой на device dm-4, в то время как при запуске ОС fsck ругается на один из реальных RAID-разделов - /dev/mapper/isw_bjhfeadcfa_Volume03, который смонтирован в /home. Все разделы на RAID-массиве перечислены в /etc/fstab:

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

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
/dev/mapper/isw_bjhfeadcfa_Volume02 /               ext4    errors=remount-ro 0       1
/dev/mapper/isw_bjhfeadcfa_Volume03 /home           ext4    defaults,acl        0       2
/dev/mapper/isw_bjhfeadcfa_Volume01 none            swap    sw              0       0
/dev/sdc4       /media/usb0     auto    rw,user,noauto  0       0


Думаю отмонтировать /dev/mapper/isw_bjhfeadcfa_Volume03, слить его содержимое на жёсткий диск для бекапов, отформатировать этот раздел, и заново восстановить данные для бэкапа. Верна ли последовательность действий?

[gardarea51]

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

ls -l /dev/mapper

[yura3d]

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

ls -l /dev/mapper

В том то и дело, что среди перечисленных устройств нету dm-4:

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

crw------- 1 root root 10, 59 Фев 19 13:33 control
lrwxrwxrwx 1 root root      7 Фев 19 13:33 isw_bjhfeadcfa_Volume0 -> ../dm-0
lrwxrwxrwx 1 root root      7 Фев 19 13:33 isw_bjhfeadcfa_Volume01 -> ../dm-1
lrwxrwxrwx 1 root root      7 Фев 19 13:33 isw_bjhfeadcfa_Volume02 -> ../dm-2
lrwxrwxrwx 1 root root      7 Фев 19 13:33 isw_bjhfeadcfa_Volume03 -> ../dm-3

Сообщение объединено: 19 февраля 2013, 22:41:18
Итак, после создания резервной копии (образа) на отдельном жёстком диске (сегодня-таки приобрели ещё один винт в сервер специально для бекапов), решил рискнуть и проверить с помощью fsck проблемный раздел. Было восстановлено в папку lost+found 2 повреждённых файла, ошибок при запуске системы больше нет. Но самое интересное, что в device mapper ранее проблемному диску стал соответствовать уже dm-4, а не dm-3, как было ранее:

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

root@server:~# ls -l /dev/mapper
итого 0
crw------- 1 root root 10, 59 Фев 19 21:08 control
lrwxrwxrwx 1 root root      7 Фев 19 21:08 isw_bjhfeadcfa_Volume0 -> ../dm-0
lrwxrwxrwx 1 root root      7 Фев 19 21:08 isw_bjhfeadcfa_Volume01 -> ../dm-1
lrwxrwxrwx 1 root root      7 Фев 19 21:08 isw_bjhfeadcfa_Volume02 -> ../dm-3
lrwxrwxrwx 1 root root      7 Фев 19 21:08 isw_bjhfeadcfa_Volume03 -> ../dm-4

Отсюда вопрос, почему это произошло?
Также, теперь при запуске системы и в логах появляются сообщения mounted filesystem with ordered data mode:

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

EXT4-fs (dm-4): mounted filesystem with ordered data mode
EXT4-fs (sdc1): mounted filesystem with ordered data mode
EXT4-fs (sdc2): mounted filesystem with ordered data mode
Насколько я понял, это не ошибка, но всё равно хотелось бы знать, что означает это сообщение и почему для некоторых разделов (например, на котором установлена ОС) оно не выводится. Раздел dm-4 - это ранее проблемный (повреждённый) раздел на fake-RAID-массиве (созданном dmraid), а sdc1 и sdc2 - разделы на свежеприобретённом жёстком диске для бекапов.