LINUX.ORG.RU
Форум — General  

[xfs][ненависть][жопа] Сижу под root'ом. Что делать?

 ,


0

0 

Ухожу в 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 не надёжнее, то хотя бы сильно быстрее :)
★★★★★

А много свободного места было на разделе перед издыханием? Если мне память не изменяет, то подобная фигня происходит когда раздел заполняется полностью.

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

>А много свободного места было на разделе перед издыханием? Если мне память не изменяет, то подобная фигня происходит когда раздел заполняется полностью.

/dev/mapper/balvg-home 145G 145G 383M 100% /home

...

Если так - ещё один камушек в сторону XFS. Под ReiserFS у меня десятки раз место кончалось в ноль :)

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

> В итоге результат как живой, но масса файлов, либо забитых нулями (опять коронная фишка XFS!), либо... вообще тупо пропавших. Был файл - нет файла...

lost+found смотрел?

У меня тоже на аналогичном объеме XFS как-то слетела. 80% удалось восстановить. Пропало около 10 Гиг из 250, в том числе бэкап с последнего места работы... :-(.

> Даже если reiser4 не надёжнее, то хотя бы сильно быстрее :)

ext3?

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

>lost+found смотрел?

Нету такого. Искал, естественно :)

>ext3?

Один раз, правда, было это лет 5 назад, на работе упала ночью на тамошнем сервере. При чём там восстановить раздел уже не удалось.

Ну и ещё один раз недавно упала на древнем сабноуте после регулярных отрубаний питания «по-живому». В целом ожила, но часть системных файлов оказалась повреждена.

...

ИМХО, любая FS способна упасть. Так что смотреть надо на иные критерии :)

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

>Если так - ещё один камушек в сторону XFS.

Наша песня хороша, начинай сначала.
У меня десятки раз место кончалось в ноль на разделе XFS с р2р закачками и ничего.
Карма, ничего не поделаешь.

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

>У меня десятки раз место кончалось в ноль на разделе XFS с р2р закачками и ничего.

Ну, значит, не в этом дело :)

>Карма, ничего не поделаешь.

Угу :)

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

Похожая фигня случилась у меня с разделом под Reiser4 при отсутствии места. Правда всё монтировалось и работало, насторожили странные падения программ. Проверка с livecd показала испортившиеся ссылки на десяток файлов, 3 из них системные. Не смертельно но неприятно.

PS А очень медленная работа fschk для reiser4 это нормально? 15гб проверяет минут 6.

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

>PS А очень медленная работа fschk для reiser4 это нормально?

Х.З., пока не доводилось.

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

>В фоне крутятся только rtorrent

Я протормозил. rtorrent у меня качает на другой раздел.

Выходит, /home вообще не использовалась ночью.

Т.е. FS отвалилась совсем без нагрузки :)

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

Бегло посмотрел в поисковике на предмет "XFS internal error xfs_alloc_read_agf" - такое ощущение что этот баг проявляется только на raid.

koTuk ☆
()

Багрепорт завёл?

anonymous
()
Ответ на: комментарий от KRoN73

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

anonymous
()
Ответ на: комментарий от sdio

сделал 3 попытки, не получилось

LVM, xfs, kernel-2.6.26-1-amd64, Debian Lenny

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

>Возможно начался тупо сыпаться диск. Несколько секторов зарелокейтились и всё

1. Релокейт секторов происходит прозрачно уже на уровне интерфейса HDD.

2. 

# lvdisplay -m /dev/balvg/home|grep -i phys
    Physical volume     /dev/sda4
    Physical extents    0 to 37119

# smartctl -a /dev/sda4|grep -i realloc
  5 Reallocated_Sector_Ct   0x0033   253   253   010    Pre-fail  Always       -       0
196 Reallocated_Event_Count 0x0032   253   253   000    Old_age   Always       -       0

По нулям.

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

# smartctl -a /dev/sda4|grep -i realloc 5 Reallocated_Sector_Ct 0x0033 253 253 010 Pre-fail Always - 0 196 Reallocated_Event_Count 0x0032 253 253 000 Old_age Always - 0

Смарту конечно можно верить, особенно на дисках самсунг... Судя по нему у меня диск на буке купленном чуть больше года назад проработал уже лет 30 :)

koTuk ☆
()
Ответ на: комментарий от koTuk

Ну, уж по любому верить можно больше, чем Сигейтам :D

...

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

Более того, у меня на одном винте с тоннами бэдов reiserfs проработала около полугода, пока, наконец, замену не организовл :) На сервере с миллионом http-запросов в сутки... И ничего не упало. Только когда я по ночам прогонял тест поверхности на предмет пополнения бэдблок-листа, машина почти вешалась.

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

>Более того, у меня на одном винте с тоннами бэдов reiserfs проработала около полугода, пока, наконец, замену не организовл

Ну что я говорил? Будем надеяться что Ему все таки дадут ноутбук с инфернетом.

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

Как-то давно (года 3 назад) у меня БП издыхал - периодически отрубал питание. XFS систематически забивала нулями открытые файлы.

Плюнул на скорость и уже год использую софтовое зеркало и ext3 data=journal

anonymous
()
Ответ на: комментарий от KRoN73

> У меня - LVM.

Все равно, не физический диск. Причина на самом деле давно известна: переполнение стека ядра, т.к. файловая система XFS использует больше стекового пространства, чем другие.

Для чтения файла ядро вызывает функцию в модуле файловой системы, она вызывает функцию чтения с поблочного устройства (в твоем случае - device mapper), оно обращается в стек SCSI, и наконец к драйверу реального SCSI-контроллера. Каждая из этих функций занимает некоторое количество стекового пространства. Однако, всего стека 8 килобайт, причем обработчики прерываний используют тот же стек. Т.е. в момент обращения к файловой системе XFS еще обрабатывалось прерывание, скажем, от сетевой карты - и стек переполнился, а содержимое памяти попортилось.

Выход - неиспользование XFS на чем либо, кроме разделов /dev/sda, и нехранение ISO- и особенно UDF-образов на ней (если смонтировать ISO-образ, то драйвер loop-устройства тоже съест часть стека при чтении файлов). А лучше этот XFS вообще выбросить.

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

> сделал 3 попытки, не получилось LVM, xfs, kernel-2.6.26-1-amd64, Debian Lenny

И

> Выход - неиспользование XFS на чем либо, кроме разделов /dev/sda

Что-то не вяжется...

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

> Что-то не вяжется...

Ну воспроизводимость еще зависит от глубины стека, необходимой SCSI-драйверу и обработчику прерываний от сетевой карты (или чего там еще)... Так что противоречия нет.

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

Я реально и инскренне хочу воспроизвести ситуацию. Давай придумаем 
как загрузить ядро, чтобы попортился стэк. Могу смонтировать пару .iso
расположенных на разделе XFS (на LVM) и активно читать с них (с .iso) 
и одновременно писать на XFS.

Кстати писал я так:

for i in `seq -w 1 20`; do
  dd if=/dev/zero of=$i.file bs=8192 &
done
wait

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

> неиспользование XFS на чем либо, кроме разделов /dev/sda

Между нами говоря, я до сих пор не втыкаю, что заставляет людей лепить конструкции вида raid+lvm из девайсов типа /dev/sd*1. Нахер делать столько костылей, если можно напрямую как в железных контроллерах отвести весь винт и будет всё ништяк и гораздо шустрее? о_О

Gharik ☆
()
Ответ на: комментарий от sdio

У меня ситуация с переполнением стека воспроизвелась какое-то время назад (заведомо больше полутора лет), когда я с делал примерно следующее:

Исходная ситуация: 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.

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

> что заставляет людей лепить конструкции вида raid+lvm из девайсов типа /dev/sd*1

Наличие fakeraid'ов в BIOS. LVM удобен для создания snapshot'ов, которые занимают мало места. Ну и шифрование всего диска через dm-crypt никто не отменял.

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

> словил oops

Кстати, насчет того, что причина - переполнение стека, я уверен, поскольку потом я все-таки дождался завершения ntfsclone непсредственно на UDF на DVD (т.е. без промежуточного UDF-образа на LVM), и oops'а не было.

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

>Ну воспроизводимость еще зависит от глубины стека

Кстати. А не увеличивает ли загрузку стека использование ionice? Типа, если запрос с idle-приоритетом начинает ждать, пока дисковая подсистема освободится?

А то я как раз перед падением системы, вечером, перевёл tracker/prelink/etc на использование ionice с idle-приоритетом :)

...

Правда, после восстановления, каждую ночь они снова крутятся и сейчас - ничего не падает.

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

> И надо же так, чтобы FS отлетела на ровном месте

А что, кабинет с компом был опечатан?

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

>А что, кабинет с компом был опечатан?

Сервер у меня на кухне стоит. Разве что кошка могла FS обвалить, ага :)

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

Проверил с loop образом udf.
При записи в несколько потоков (в моем случае четыре cp -R ... &)
Ловил oops независимо от того где лежал udf.img
Проверялись:
 1. /dev/sdc1 + lvm + xfs  + udf.img (loop)
 2. /dev/sdc1 + lvm + ext3 + udf.img (loop)
 3. /dev/sdb8 +       ext3 + udf.img (loop)

Так что в данном случае не XFS источник проблемы.

 *** dmesg ***

Sep  5 12:41:34 sdio kernel: [ 1246.080670] ------------[ cut here ]------------
Sep  5 12:41:34 sdio kernel: [ 1246.080670] kernel BUG at fs/inode.c:191!
Sep  5 12:41:34 sdio kernel: [ 1246.080670] invalid opcode: 0000 [1] SMP 
Sep  5 12:41:34 sdio kernel: [ 1246.080670] CPU 1 
Sep  5 12:41:34 sdio kernel: [ 1246.080670] Modules linked in: udf nls_base crc_itu_t ...
Sep  5 12:41:34 sdio kernel: ansport_spi ata_generic libata scsi_mod dock ehci_hcd ohci_hcd r8169 thermal processor fan therm
Sep  5 12:41:34 sdio kernel: [ 1246.080670] Pid: 3914, comm: cp Tainted: P          2.6.26-1-amd64 #1
Sep  5 12:41:34 sdio kernel: [ 1246.080670] RIP: 0010:[<ffffffff802acaf2>]  [<ffffffff802acaf2>] destroy_inode+0xd/0x47
Sep  5 12:41:34 sdio kernel: [ 1246.080670] RSP: 0018:ffff81002b4a7918  EFLAGS: 00010202
Sep  5 12:41:34 sdio kernel: [ 1246.080670] RAX: 0000000000000001 RBX: ffff810004b99308 RCX: ffff810004b99308
Sep  5 12:41:34 sdio kernel: [ 1246.080670] RDX: 0000000000000007 RSI: ffff810004b99510 RDI: ffff810004b99308
Sep  5 12:41:34 sdio kernel: [ 1246.080670] RBP: ffff810004b99308 R08: 0000000000000000 R09: 0000000000000010
Sep  5 12:41:34 sdio kernel: [ 1246.080670] R10: ffffe200007923c0 R11: 00000000fffffffa R12: 000000000000003a
Sep  5 12:41:34 sdio kernel: [ 1246.080670] R13: ffff81002b4a7958 R14: 0000000000000080 R15: 0000000000000100
Sep  5 12:41:34 sdio kernel: [ 1246.080670] FS:  00007f47c87e3770(0000) GS:ffff81003b9f69c0(0000) knlGS:00000000f7d8a6b0
Sep  5 12:41:34 sdio kernel: [ 1246.080670] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Sep  5 12:41:34 sdio kernel: [ 1246.080670] CR2: 0000000000a3f268 CR3: 000000002b5a1000 CR4: 00000000000006e0
Sep  5 12:41:34 sdio kernel: [ 1246.080670] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Sep  5 12:41:34 sdio kernel: [ 1246.080670] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Sep  5 12:41:34 sdio kernel: [ 1246.080670] Process cp (pid: 3914, threadinfo ffff81002b4a6000, task ffff81003ac58b90)
Sep  5 12:41:34 sdio kernel: [ 1246.080670] Stack:  ffff810004b99318 ffffffff802ad107 0000000000000000 ffff810028eef7f8
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  0000000000000000 0000000000000080 0000000000000080 ffffffff802ad306
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  ffff810028c97010 ffff810034149010 ffffffff80505ae0 0000000000000a28
Sep  5 12:41:34 sdio kernel: [ 1246.080670] Call Trace:
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  [<ffffffff802ad107>] ? dispose_list+0xbf/0xee
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  [<ffffffff802ad306>] ? shrink_icache_memory+0x1d0/0x200
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  [<ffffffff8027b079>] ? shrink_slab+0xe2/0x159
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  [<ffffffff8027b344>] ? try_to_free_pages+0x254/0x35a
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  [<ffffffff8027a38b>] ? isolate_pages_global+0x0/0x2f
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  [<ffffffff8027678e>] ? __alloc_pages_internal+0x26f/0x3c4
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  [<ffffffffa068e15c>] ? :udf:udf_get_block+0x0/0x10b6
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  [<ffffffff802711cc>] ? __grab_cache_page+0x33/0x6f
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  [<ffffffff802bb2e1>] ? block_write_begin+0x38/0xcc
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  [<ffffffffa068c5b2>] ? :udf:udf_write_begin+0x22/0x27
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  [<ffffffffa068e15c>] ? :udf:udf_get_block+0x0/0x10b6
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  [<ffffffff80271ba2>] ? generic_file_buffered_write+0x14c/0x630
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  [<ffffffff80305919>] ? cap_inode_need_killpriv+0x0/0x3b
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  [<ffffffff80238a05>] ? current_fs_time+0x1e/0x24
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  [<ffffffff8027096e>] ? remove_suid+0x18/0x4b
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  [<ffffffff802723c5>] ? __generic_file_aio_write_nolock+0x33f/0x3a9
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  [<ffffffff802b0343>] ? mnt_drop_write+0x25/0xdd
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  [<ffffffff80272490>] ? generic_file_aio_write+0x61/0xc1
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  [<ffffffffa068bf5a>] ? :udf:udf_file_aio_write+0xcc/0xf3
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  [<ffffffff8029a9a7>] ? do_sync_write+0xc9/0x10c
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  [<ffffffff80246021>] ? autoremove_wake_function+0x0/0x2e
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  [<ffffffff8020a893>] ? __switch_to+0xd2/0x35e
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  [<ffffffff8022f012>] ? hrtick_set+0x88/0xf7
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  [<ffffffff8029b151>] ? vfs_write+0xad/0x156
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  [<ffffffff8029b68d>] ? sys_read+0x4d/0x6e
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  [<ffffffff8029b6f3>] ? sys_write+0x45/0x6e
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  [<ffffffff8020bf49>] ? sysret_signal+0x2b/0x45
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  [<ffffffff8020be9a>] ? system_call_after_swapgs+0x8a/0x8f
Sep  5 12:41:34 sdio kernel: [ 1246.080670] 
Sep  5 12:41:34 sdio kernel: [ 1246.080670] 
Sep  5 12:41:34 sdio kernel: [ 1246.080670] Code: 83 bb c0 01 00 00 00 74 08 48 89 df e8 3c 06 ff ff 48 c7 83 08 02 00 00 40 
Sep  5 12:41:34 sdio kernel: [ 1246.080670] RIP  [<ffffffff802acaf2>] destroy_inode+0xd/0x47
Sep  5 12:41:34 sdio kernel: [ 1246.080670]  RSP <ffff81002b4a7918>
Sep  5 12:41:34 sdio kernel: [ 1246.080670] ---[ end trace 2ae82ca70292a3fa ]---

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

> Так что в данном случае не XFS источник проблемы.

А я и не говорил, что у меня когда-либо был XFS :) просто демонстрировал переполнение стека.

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

> Кстати. А не увеличивает ли загрузку стека использование ionice? Типа, если запрос с idle-приоритетом начинает ждать, пока дисковая подсистема освободится?

Ну и пусть ждет. Тогда выполняется совсем другой процесс или поток ядра, с отдельным стеком.

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

К тебе претензий и не было :-)
Просто тут сразу крики раздались в адрес XFS, притом что истинная причина её сбоя не была выяснена.

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

>Просто тут сразу крики раздались в адрес XFS, притом что истинная причина её сбоя не была выяснена.

Так вопрос не в причинах сбоя.

Вопрос в том, как тяжело она этот сбой пережила.

Мало доверия файловой системе, которая может потерять массу файлов даже при отсутствии заметной записи на диск.

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

Очень хотелось бы выяснить причины.

Сам понимаешь, единичные проблемы/успехи ЛОРовцев типа "а у меня (не) работает" мало кому интересно, так как не отражает истины и на реальность никак не отображается.

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

> Просто тут сразу крики раздались в адрес XFS, притом что истинная причина её сбоя не была выяснена.

Так почитай LKML - про XFS и стек все еще говорят, особенно когда обсуждают переход по умолчанию на стек 4 КБ + отдельные 4 КБ для прерываний (вместо 8 КБ для всего вместе). Правда, в последний раз, когда эта идея обсуждалась (см. обзор в http://lwn.net/Articles/279229/ ), ее вроде похоронили.

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

>Очень хотелось бы выяснить причины.

Ну, машина продолжает работать в том же режиме, что и раньше, разве что места в /home теперь больше. Пока не падает. Экспериментировать снова с заполнением диска на живой машине неохота :)

А на счёт экспериментов... Ну, попробую воспроизвести как-нить ситуацию после покупки ещё одного винта.

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

Я тут пару-тройку дней назад пылесосил второй торрент-недосервир, что стоит на кухне в пыли и жарюке. И чо случилось - только открыл корпус и начал жалом пыль вытягивать - так глюканул винт, дегрейднулся рейд и запустился ребилд на один из хот-спарей.

А потом эта херь внезапно ресетнулась. Чо там случилось - хз, но рейд наебнулся так, что восстанавливал я его пару дней с имиджей винтов (потому и пару дней). 90% вытянулось, несколько рейд-партишенов похерилось.

А всё почему? А всё потому, что /dev/sd[a-h][1-11]. Ибо 11 софтрейдов = 11 точек отказа, а 1 (АДЫН!) рейд, что и творится на всех остальных стораджах = паранойя, бэкапы и простое восстановление.

А LVM нахуй, да простят слова сии мне дамы и прочий слабый пол.

Gharik ☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
General