Ухожу в 6 утра после работы спать, с машиной всё ок. В фоне крутятся
только rtorrent, даже nightly-процессы уже все с 3 до 4 ночи отработали.
Утром прихожу - машина ругается на каждый чих. Типа, DCOP отвалился, не
могу записать /home/balancer/.kde/ля-ля-ля.rc
Иду в /home смотреть, мало ли чего с правами.
Опаньки, в /home не пускает. Ошибка, говорит.
Лезу в dmesg:
Filesystem "dm-0": XFS internal error xfs_alloc_read_agf at line 2195 of file fs/xfs/xfs_alloc.c. Caller 0xc02ce8e7
Pid: 22295, comm: opera Tainted: P M 2.6.25-tuxonice-r4 #1
[<c02cc5ff>] xfs_alloc_read_agf+0xc4/0x1c2
[<c02ce8e7>] xfs_alloc_fix_freelist+0x412/0x49d
[<c02ce8e7>] xfs_alloc_fix_freelist+0x412/0x49d
[<c0312837>] xfs_trans_tail_ail+0x16/0x43
[<c02ce8e7>] xfs_alloc_fix_freelist+0x412/0x49d
[<c03065a6>] xfs_log_release_iclog+0x11/0x38
[<c0312529>] _xfs_trans_commit+0x21e/0x345
[<c031367a>] xfs_trans_log_inode+0x11/0x2b
[<c02df374>] xfs_bunmapi+0x720/0xa21
[<c02cea02>] xfs_free_extent+0x90/0xd4
[<c0304b85>] xlog_grant_push_ail+0x30/0x112
[<c02d8ae4>] xfs_bmap_finish+0x117/0x15e
[<c02fcca5>] xfs_itruncate_finish+0x25f/0x3d7
[<c031b0a0>] xfs_inactive+0x386/0x49b
[<c0324380>] xfs_fs_clear_inode+0x34/0x82
[<c019b64d>] invalidate_inode_buffers+0xa/0x8d
[<c018c6aa>] clear_inode+0x52/0xe8
[<c018c855>] generic_delete_inode+0xdb/0xf8
[<c018c12e>] iput+0x5c/0x62
[<c01839db>] do_unlinkat+0xcc/0x124
[<c0103cee>] sysenter_past_esp+0x5f/0x85
[<c04a0000>] quirk_usb_early_handoff+0x10a/0x46a
=======================
xfs_force_shutdown(dm-0,0x8) called from line 4258 of file fs/xfs/xfs_bmap.c. Return address = 0xc02d8b26
Filesystem "dm-0": Corruption of in-memory data detected. Shutting down filesystem: dm-0
Please umount the filesystem, and rectify the problem(s)
так-так... Отмонтировать не выходит, даже на "-l" система раздел не
освобождает. Перегружаю. Бодро репортует о chk для этого раздела,
монтирует... Опаньки. Дальше -та же фигня.
Снимаю автомонтирование /home, слава Богу, он у меня отдельным разделом,
перегружаюсь, монтирую от root'а вручную - всё ок. Раздел с виду на
месте, но в dmesg:
XFS mounting filesystem dm-0
Starting XFS recovery on filesystem: dm-0 (logdev: internal)
00000000: 58 41 47 46 00 00 00 01 00 00 00 09 00 24 40 00 XAGF.........$@.
Filesystem "dm-0": XFS internal error xfs_alloc_read_agf at line 2195 of file fs/xfs/xfs_alloc.c. Caller 0xc02ce811
Pid: 11513, comm: mount Tainted: P 2.6.25-tuxonice-r4 #1
[<c02cc5ff>] xfs_alloc_read_agf+0xc4/0x1c2
[<c02ce811>] xfs_alloc_fix_freelist+0x33c/0x49d
[<c02ce811>] xfs_alloc_fix_freelist+0x33c/0x49d
[<c02ce811>] xfs_alloc_fix_freelist+0x33c/0x49d
[<c015ddbb>] __alloc_pages+0x54/0x343
[<c0176c20>] __slab_alloc+0x286/0x49a
[<c031ddf9>] xfs_buf_iowait+0x33/0x3c
[<c02cea02>] xfs_free_extent+0x90/0xd4
[<c0304b85>] xlog_grant_push_ail+0x30/0x112
[<c0307a74>] xlog_recover_process_efi+0x201/0x23d
[<c030aa2c>] xlog_recover_process_efis+0x49/0x9f
[<c030aa99>] xlog_recover_finish+0x17/0xad
[<c02fa085>] xfs_iunlock+0x38/0x6a
[<c030eb9c>] xfs_mountfs+0x538/0x6ee
[<c02f37c1>] xfs_fs_vcmn_err+0x69/0x8f
[<c031befe>] kmem_zalloc+0xd/0x36
[<c0315a1c>] xfs_mount+0x2fe/0x332
[<c0325445>] xfs_fs_fill_super+0x96/0x1b5
[<c017c020>] get_sb_bdev+0xe7/0x10d
[<c0180c82>] permission+0x6a/0x107
[<c03240ad>] xfs_fs_get_sb+0x20/0x25
[<c03253af>] xfs_fs_fill_super+0x0/0x1b5
[<c017bda7>] vfs_kern_mount+0x5d/0x11d
[<c017beae>] do_kern_mount+0x31/0xbc
[<c018fd0c>] do_new_mount+0x69/0x8e
[<c01901eb>] do_mount+0x179/0x1c7
[<c018e7ff>] copy_mount_options+0x28/0x12a
[<c0182234>] getname+0x7b/0xbe
[<c01902b0>] sys_mount+0x77/0xae
[<c0103cee>] sysenter_past_esp+0x5f/0x85
=======================
Ending XFS recovery on filesystem: dm-0 (logdev: internal)
Ладно, проверяем. Ага:
# xfs_check /dev/balvg/home
agi_freecount 153407, counted 153405 in ag 7
agf_freeblks 4294967293, counted 12 in ag 9
block 9/528161 type unknown not expected
block 9/528162 type unknown not expected
block 9/528163 type unknown not expected
block 9/528164 type unknown not expected
block 9/528165 type unknown not expected
block 9/528166 type unknown not expected
block 9/528167 type unknown not expected
Запускаю xfs_repair... Долго мучает раздел (как-никак 200+Гб),
В итоге результат как живой, но масса файлов, либо забитых нулями
(опять коронная фишка XFS!), либо... вообще тупо пропавших.
Был файл - нет файла...
...
Правы были те умные люди, которые на ЛОРе говорили, что у меня
для работы с XFS карма не подходит :)
Хотя всё равно не понимаю, чего накурившись надо было делать FS
с таким поведением в отношении сбоев (зануления).
И надо же так, чтобы FS отлетела на ровном месте, даже с работой с
диском в основном на чтении, на машине с за много лет проверенным
железом, с большим аптаймом... Нет, надо срочно покупать второй
винт, переносить туда систему под reiser4 и делать массовые бэкапы... :)
Даже если reiser4 не надёжнее, то хотя бы сильно быстрее :)
А много свободного места было на разделе перед издыханием?
Если мне память не изменяет, то подобная фигня происходит когда раздел заполняется полностью.
>А много свободного места было на разделе перед издыханием? Если мне память не изменяет, то подобная фигня происходит когда раздел заполняется полностью.
/dev/mapper/balvg-home 145G 145G 383M 100% /home
...
Если так - ещё один камушек в сторону XFS. Под ReiserFS у меня десятки раз место кончалось в ноль :)
> В итоге результат как живой, но масса файлов, либо забитых нулями
(опять коронная фишка XFS!), либо... вообще тупо пропавших.
Был файл - нет файла...
lost+found смотрел?
У меня тоже на аналогичном объеме XFS как-то слетела. 80% удалось восстановить. Пропало около 10 Гиг из 250, в том числе бэкап с последнего места работы... :-(.
> Даже если reiser4 не надёжнее, то хотя бы сильно быстрее :)
Один раз, правда, было это лет 5 назад, на работе упала ночью на тамошнем сервере. При чём там восстановить раздел уже не удалось.
Ну и ещё один раз недавно упала на древнем сабноуте после регулярных отрубаний питания «по-живому». В целом ожила, но часть системных файлов оказалась повреждена.
...
ИМХО, любая FS способна упасть. Так что смотреть надо на иные критерии :)
Похожая фигня случилась у меня с разделом под Reiser4 при отсутствии места. Правда всё монтировалось и работало, насторожили странные падения программ. Проверка с livecd показала испортившиеся ссылки на десяток файлов, 3 из них системные. Не смертельно но неприятно.
PS А очень медленная работа fschk для reiser4 это нормально? 15гб проверяет минут 6.
Ну, уж по любому верить можно больше, чем Сигейтам :D
...
Как бы там ни было, повторюсь, релокейт вообще прозрачен для системы, пока не полезут бэды.
Более того, у меня на одном винте с тоннами бэдов reiserfs проработала около полугода, пока, наконец, замену не организовл :) На сервере с миллионом http-запросов в сутки... И ничего не упало. Только когда я по ночам прогонял тест поверхности на предмет пополнения бэдблок-листа, машина почти вешалась.
Все равно, не физический диск. Причина на самом деле давно известна: переполнение стека ядра, т.к. файловая система XFS использует больше стекового пространства, чем другие.
Для чтения файла ядро вызывает функцию в модуле файловой системы, она вызывает функцию чтения с поблочного устройства (в твоем случае - device mapper), оно обращается в стек SCSI, и наконец к драйверу реального SCSI-контроллера. Каждая из этих функций занимает некоторое количество стекового пространства. Однако, всего стека 8 килобайт, причем обработчики прерываний используют тот же стек. Т.е. в момент обращения к файловой системе XFS еще обрабатывалось прерывание, скажем, от сетевой карты - и стек переполнился, а содержимое памяти попортилось.
Выход - неиспользование XFS на чем либо, кроме разделов /dev/sda, и нехранение ISO- и особенно UDF-образов на ней (если смонтировать ISO-образ, то драйвер loop-устройства тоже съест часть стека при чтении файлов). А лучше этот XFS вообще выбросить.
Ну воспроизводимость еще зависит от глубины стека, необходимой SCSI-драйверу и обработчику прерываний от сетевой карты (или чего там еще)... Так что противоречия нет.
Я реально и инскренне хочу воспроизвести ситуацию. Давай придумаем
как загрузить ядро, чтобы попортился стэк. Могу смонтировать пару .iso
расположенных на разделе XFS (на LVM) и активно читать с них (с .iso)
и одновременно писать на XFS.
Кстати писал я так:
for i in `seq -w 1 20`; do
dd if=/dev/zero of=$i.file bs=8192 &
done
wait
> неиспользование XFS на чем либо, кроме разделов /dev/sda
Между нами говоря, я до сих пор не втыкаю, что заставляет людей лепить конструкции вида raid+lvm из девайсов типа /dev/sd*1. Нахер делать столько костылей, если можно напрямую как в железных контроллерах отвести весь винт и будет всё ништяк и гораздо шустрее? о_О
У меня ситуация с переполнением стека воспроизвелась какое-то время назад (заведомо больше полутора лет), когда я с делал примерно следующее:
Исходная ситуация: LVM с большим количеством свободного места на большом диске /dev/hda, и WinXP, подлежащая backup'у, на маленьком старом диске /dev/hdc. Оборудование - старая материнская плата на чипсете от VIA. Размер раздела с NTFS порядка 6 GB, но удалось освободить 2 GB места путем удаления ненужных файлов. Backup планировалось сделать путем пакетной записи посекторного образа NTFS на DVD+RW, отформатированный в UDF (чтобы получился sparse file, и чтобы была возможность поправлять образ путем монтирования через loop). К сожалению, ntfsclone непосредственно на DVD тормозит, поэтому было решено создать UDF-образ, смонтировать через loop, записать туда NTFS-образ с помощью ntfsclone, и потом записать UDF-образ на DVD.
Итого (примерно - я сейчас на работе):
dd if=/dev/null of=udf.img bs=1M seek=4482 # заметим, что файл образа тоже дырявый
mkudffs udf.img
mount -t udf -o loop udf.umg /mnt/udf
ntfsclone -O /mnt/udf/winxp.ntfs /dev/hdc1
и то ли во время ntfsclone, то ли при проверке монтированием /mnt/udf/winxp.ntfs через еще один loop (уже не помню), я словил oops.
> что заставляет людей лепить конструкции вида raid+lvm из девайсов типа /dev/sd*1
Наличие fakeraid'ов в BIOS. LVM удобен для создания snapshot'ов, которые занимают мало места. Ну и шифрование всего диска через dm-crypt никто не отменял.
Кстати, насчет того, что причина - переполнение стека, я уверен, поскольку потом я все-таки дождался завершения ntfsclone непсредственно на UDF на DVD (т.е. без промежуточного UDF-образа на LVM), и oops'а не было.
>Ну воспроизводимость еще зависит от глубины стека
Кстати. А не увеличивает ли загрузку стека использование ionice? Типа, если запрос с idle-приоритетом начинает ждать, пока дисковая подсистема освободится?
А то я как раз перед падением системы, вечером, перевёл tracker/prelink/etc на использование ionice с idle-приоритетом :)
...
Правда, после восстановления, каждую ночь они снова крутятся и сейчас - ничего не падает.
> Кстати. А не увеличивает ли загрузку стека использование ionice? Типа, если запрос с idle-приоритетом начинает ждать, пока дисковая подсистема освободится?
Ну и пусть ждет. Тогда выполняется совсем другой процесс или поток ядра, с отдельным стеком.
Сам понимаешь, единичные проблемы/успехи ЛОРовцев типа "а у меня (не) работает" мало кому интересно, так как не отражает истины и на реальность никак не отображается.
> Просто тут сразу крики раздались в адрес XFS, притом что истинная причина её сбоя не была выяснена.
Так почитай LKML - про XFS и стек все еще говорят, особенно когда обсуждают переход по умолчанию на стек 4 КБ + отдельные 4 КБ для прерываний (вместо 8 КБ для всего вместе). Правда, в последний раз, когда эта идея обсуждалась (см. обзор в http://lwn.net/Articles/279229/ ), ее вроде похоронили.
Ну, машина продолжает работать в том же режиме, что и раньше, разве что места в /home теперь больше. Пока не падает. Экспериментировать снова с заполнением диска на живой машине неохота :)
А на счёт экспериментов... Ну, попробую воспроизвести как-нить ситуацию после покупки ещё одного винта.
Я тут пару-тройку дней назад пылесосил второй торрент-недосервир, что стоит на кухне в пыли и жарюке. И чо случилось - только открыл корпус и начал жалом пыль вытягивать - так глюканул винт, дегрейднулся рейд и запустился ребилд на один из хот-спарей.
А потом эта херь внезапно ресетнулась. Чо там случилось - хз, но рейд наебнулся так, что восстанавливал я его пару дней с имиджей винтов (потому и пару дней). 90% вытянулось, несколько рейд-партишенов похерилось.
А всё почему? А всё потому, что /dev/sd[a-h][1-11]. Ибо 11 софтрейдов = 11 точек отказа, а 1 (АДЫН!) рейд, что и творится на всех остальных стораджах = паранойя, бэкапы и простое восстановление.
А LVM нахуй, да простят слова сии мне дамы и прочий слабый пол.