Использование 3dm2 в SUSE 10 (и FC 2/3) для 3ware 9500S
Модераторы: Trinity admin`s, Free-lance moderator`s
-
- Junior member
- Сообщения: 6
- Зарегистрирован: 17 апр 2006, 12:49
Использование 3dm2 в SUSE 10 (и FC 2/3) для 3ware 9500S
Приветствую всех.
Сейчас у меня огромные проблемы с RAID'ом. Я пытался написать всю историю "пикирующего бомбардировщика", но это заняло _уже_ 28 килобайт (с кусками логов), и это только половина истории. Поэтому, дабы никого не грузить лишней информацией, просто задам такой вот маленький вопрос.
Необходимо ли обязательное использование 3dm2 при работе с RAID-5 в *nix? Честно говоря, я не до конца разобрался (точнее, окончательно запутался) в драйверах-службах, нужных для нормального функционирования RAID на базе 3ware 9500S-8 под Fedora Core 2/3 и SUSE 10. И если нужно, то где в SUSE этот 3dm2?
Как выглядит проблема вкратце (_очень_ вкратце). После какого-то таймаута (от полторы минуты после перезагрузки, до полутора дней) файловая система etx3 (на одном из разделов, находящемся на /dev/sda) выходит в режим read-only из-за ошибки журнала (как минимум: ext3_add_entry, ext3_readdir, ext3_new_block). Лечится перезагрузкой/e2fsck, но повторяется и повторяется.
Работа стоит уже несколько дней. Помогите, пожалуйста. Всю необходимую информацию предоставлю.
Сейчас у меня огромные проблемы с RAID'ом. Я пытался написать всю историю "пикирующего бомбардировщика", но это заняло _уже_ 28 килобайт (с кусками логов), и это только половина истории. Поэтому, дабы никого не грузить лишней информацией, просто задам такой вот маленький вопрос.
Необходимо ли обязательное использование 3dm2 при работе с RAID-5 в *nix? Честно говоря, я не до конца разобрался (точнее, окончательно запутался) в драйверах-службах, нужных для нормального функционирования RAID на базе 3ware 9500S-8 под Fedora Core 2/3 и SUSE 10. И если нужно, то где в SUSE этот 3dm2?
Как выглядит проблема вкратце (_очень_ вкратце). После какого-то таймаута (от полторы минуты после перезагрузки, до полутора дней) файловая система etx3 (на одном из разделов, находящемся на /dev/sda) выходит в режим read-only из-за ошибки журнала (как минимум: ext3_add_entry, ext3_readdir, ext3_new_block). Лечится перезагрузкой/e2fsck, но повторяется и повторяется.
Работа стоит уже несколько дней. Помогите, пожалуйста. Всю необходимую информацию предоставлю.
-
- Junior member
- Сообщения: 6
- Зарегистрирован: 17 апр 2006, 12:49
А как бы всё-таки мне локализовать проблему?.. Узнать, железо это или драйвер? Может, есть простой способ?
Вот вырезка из лога boot.msg на SUSE (это постабильнее оказалось, нежели fedora core 2):
Note: Это уже не ext3, но после перевода одного /dev/sda1 на reiserfs.
И как можно запустить smartd для RAID'а, если он пишет следующее (/var/log/messages):
Вот вырезка из лога boot.msg на SUSE (это постабильнее оказалось, нежели fedora core 2):
Код: Выделить всё
<4>3w-9xxx: scsi0: AEN: INFO (0x04:0x0053): Battery capacity test is overdue:.
<6>scsi0 : 3ware 9000 Storage Controller
<4>3w-9xxx: scsi0: Found a 3ware 9000 Storage Controller at 0xfc8ffc00, IRQ: 169.
<4>3w-9xxx: scsi0: Firmware FE9X 2.08.00.005, BIOS BE9X 2.03.01.052, Ports: 8.
<5> Vendor: AMCC Model: 9500S-8 DISK Rev: 2.08
<5> Type: Direct-Access ANSI SCSI revision: 03
<5>SCSI device sda: 1464778752 512-byte hdwr sectors (749967 MB)
<5>SCSI device sda: drive cache: write back, no read (daft)
<5>SCSI device sda: 1464778752 512-byte hdwr sectors (749967 MB)
<5>SCSI device sda: drive cache: write back, no read (daft)
<6> sda: sda1 sda2 sda3 sda4 < sda5 >
<5>Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
<4>scsi: On host 0 channel 0 id 0 only 511 (max_scsi_report_luns) of 241994733 luns reported, try increasing max_scsi_report_luns.
<4>scsi: host 0 channel 0 id 0 lun 0x373337362030202d has a LUN larger than currently supported.
<4>scsi: host 0 channel 0 id 0 lun 0x204c697665203078 has a LUN larger than currently supported.
<4>scsi: host 0 channel 0 id 0 lun 0x6666666666666666 has a LUN larger than currently supported.
<4>scsi: host 0 channel 0 id 0 lun 0x3838303635303030 has a LUN larger than currently supported.
вот тут много-много таких lun 0х........ _ОЧЕНЬ_ много
<4>scsi: host 0 channel 0 id 0 lun 0x64652d636f72652e has a LUN larger than currently supported.
<4>scsi: host 0 channel 0 id 0 lun973761391 has a LUN larger than allowed by the host adapter
<5>Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0
<4>scsi_id[1859]: 0:0:0:0: page 0 not available.
<4>scsi_id[1862]: 0:0:0:0: page 0 not available.
И как можно запустить smartd для RAID'а, если он пишет следующее (/var/log/messages):
Код: Выделить всё
Apr 16 17:48:40 optus smartd[7794]: smartd version 5.33 [x86_64-unknown-linux-gnu] Copyright (C) 2002-4 Bruce Allen
Apr 16 17:48:40 optus smartd[7794]: Home page is http://smartmontools.sourceforge.net/
Apr 16 17:48:40 optus smartd[7794]: Opened configuration file /etc/smartd.conf
Apr 16 17:48:40 optus smartd[7794]: Drive: DEVICESCAN, implied '-a' Directive on line 23 of file /etc/smartd.conf
Apr 16 17:48:40 optus smartd[7794]: Configuration file /etc/smartd.conf was parsed, found DEVICESCAN, scanning devices
Apr 16 17:48:40 optus smartd[7794]: Device: /dev/hda, opened
Apr 16 17:48:40 optus smartd[7794]: Device: /dev/hda, not found in smartd database.
Apr 16 17:48:40 optus smartd[7794]: Device: /dev/hda, is SMART capable. Adding to "monitor" list.
Apr 16 17:48:40 optus smartd[7794]: Device: /dev/hdc, opened
Apr 16 17:48:40 optus smartd[7794]: Device: /dev/hdc, packet devices [this device CD/DVD] not SMART capable
Apr 16 17:48:40 optus smartd[7794]: Device: /dev/sda, opened
Apr 16 17:48:40 optus smartd[7794]: Device: /dev/sda, Bad IEC (SMART) mode page, err=5, skip device <-------------------------вот
Apr 16 17:48:40 optus smartd[7794]: Monitoring 1 ATA and 0 SCSI devices
Apr 16 17:48:40 optus smartd[7796]: smartd has fork()ed into background mode. New PID=7796.
Apr 16 17:48:40 optus smartd[7796]: file /var/run/smartd.pid written containing PID 7796
читая инфу с массива драйвер рапортует что у вас 241994773 луна :shock: , что есть явная ерунда.dmesg писал(а): 0 id 0 only 511 (max_scsi_report_luns) of 241994733 luns reported, try increasing max_scsi_report_luns.
<4>scsi: host 0 channel 0 id 0 lun 0x373337362030202d has a LUN larger than currently supported.
далее драйвер сообщает что у луна с номером 0x373337362030202d некие проблемы с размером. Луны вроде с номерами 0,1,2, ... 128 и тд, но не как не 0x373337362030202d
то есть налицо каой-то баг, или в кернеле/драйвере или в фирмари.
Гляньте что пишет 3-ware по этому поводу в 9000-Series Releas Notes
смартд -- это для дисков, мониторинг рэйд массивов утилитами от производителя
в приведенном выше логе ошибок от ext3 или raiserfs не показано.
рекомендация: проверьте свежесть фирмвари (если надо то обновите),
проверьте массив утилитой от 3вари, если ничего не показывает, то тогда в 3варь-суппорт, т.к. похоже это их проблема.
-
- Junior member
- Сообщения: 6
- Зарегистрирован: 17 апр 2006, 12:49
apelsin
Извиняюсь за собственную (возможно) глупость/невнимательность, но хочу всё же уточнить. Я этот releas_notes_9.2 уже читал неоднократно. Видимо, по прочтении подразумевается идти куда-то по ссылкам? Или писать в саппорт? Потому что в самом документе инфы-то немного.
>> в приведенном выше логе ошибок от ext3 или raiserfs не показано.
они выглядят так:
для ext3:
Таких падений/починок у меня уже куча.
>> проверьте массив утилитой от 3вари, если ничего не показывает
Чем? В SUSE 10 вроде уже драйвер встроен. Но чем проверить "железо"? Может, у меня в силу отсутствия опята вообще всё неправильно сконфигурено изначально, а "мужики и не знают"?
Извиняюсь за собственную (возможно) глупость/невнимательность, но хочу всё же уточнить. Я этот releas_notes_9.2 уже читал неоднократно. Видимо, по прочтении подразумевается идти куда-то по ссылкам? Или писать в саппорт? Потому что в самом документе инфы-то немного.
>> в приведенном выше логе ошибок от ext3 или raiserfs не показано.
они выглядят так:
для ext3:
Код: Выделить всё
*падение:*
Apr 13 18:59:16 optus kernel: EXT3-fs error (device sda1): ext3_new_block: Allocating block in system zone - block = 2752512
Apr 13 18:59:16 optus kernel: Aborting journal on device sda1.
Apr 13 18:59:16 optus kernel: ext3_reserve_inode_write: aborting transaction: Journal has aborted in __ext3_journal_get_write_access<2>EXT3-fs error (device sda1) in ext3_reserve_inode_write: Journal has aborted
Apr 13 18:59:16 optus kernel: ext3_abort called.
Apr 13 18:59:16 optus kernel: EXT3-fs abort (device sda1): ext3_journal_start: Detected aborted journal
Apr 13 18:59:16 optus kernel: Remounting filesystem read-only
Apr 13 18:59:16 optus kernel: EXT3-fs error (device sda1) in ext3_ordered_commit_write: Journal has aborted
Apr 13 18:59:16 optus kernel: __journal_remove_journal_head: freeing b_committed_data
*чиним ext3*
Apr 13 19:05:03 optus kernel: EXT3-fs warning (device sda1): ext3_clear_journal_err: Filesystem error recorded from previous mount: IO failure
Apr 13 19:05:03 optus kernel: EXT3-fs warning (device sda1): ext3_clear_journal_err: Marking fs in need of filesystem check.
Apr 13 19:05:03 optus kernel: EXT3-fs warning: mounting fs with errors, running e2fsck is recommended
Apr 13 19:05:03 optus kernel: EXT3 FS on sda1, internal journal
Apr 13 19:05:03 optus kernel: EXT3-fs: recovery complete.
Apr 13 19:05:03 optus kernel: EXT3-fs: mounted filesystem with ordered data mode.
Apr 13 19:05:03 optus kernel: kjournald starting. Commit interval 5 seconds
Apr 13 19:05:03 optus kernel: EXT3 FS on sda2, internal journal
Apr 13 19:05:03 optus kernel: EXT3-fs: mounted filesystem with ordered data mode.
Apr 13 19:05:04 optus kernel: kjournald starting. Commit interval 5 seconds
Apr 13 19:05:04 optus kernel: EXT3 FS on sda5, internal journal
Apr 13 19:05:04 optus kernel: EXT3-fs: mounted filesystem with ordered data mode.
*опять слетает*
Apr 14 14:40:13 optus kernel: EXT3-fs error (device sda1): ext3_new_block: Allocating block in system zone - block = 2752517
Apr 14 14:40:13 optus kernel: Aborting journal on device sda1.
Apr 14 14:40:13 optus kernel: ext3_reserve_inode_write: aborting transaction: Journal has aborted in __ext3_journal_get_write_access<2>EXT3-fs error (device sda1) in ext3_reserve_inode_write: Journal has aborted
Apr 14 14:40:13 optus kernel: ext3_abort called.
Apr 14 14:40:13 optus kernel: EXT3-fs abort (device sda1): ext3_journal_start: Detected aborted journal
Apr 14 14:40:13 optus kernel: Remounting filesystem read-only
Apr 14 14:40:13 optus kernel: EXT3-fs error (device sda1) in ext3_ordered_commit_write: Journal has aborted
Apr 14 14:40:13 optus kernel: __journal_remove_journal_head: freeing b_committed_data
>> проверьте массив утилитой от 3вари, если ничего не показывает
Чем? В SUSE 10 вроде уже драйвер встроен. Но чем проверить "железо"? Может, у меня в силу отсутствия опята вообще всё неправильно сконфигурено изначально, а "мужики и не знают"?
лог ехт3 действително показывает что контроллер как блок-девайс работает не надежно, т.е. вдуг не пишет в какие-то блоки. такого явно быть не должно.
Драйвер контроллера встроен в кернел, а утилита "для железа" от 3вари вроде называется 3dm, к ней есть дока как пользоваться. Перед тем как обращатся в суппорт неплохо знать что данная утилита говорит о состоянии массива.
в release-notes инфы действительно немного, тем не менее там есть ссылка на редхат-багзиллу в котором вероятно можно посмотреть подробности бага "слишком большой лун с непонятным номером". Важен факт что есть упонинание о похожей проблеме, что это вызвано багом, и следствие что все это изветсно в 3вари. Т.к. суза 10
довольно известная ось, скороее всего можно от суппорта услышать нечто толковое.
ПС: не думаю что это массив или контроллер, скорее всего баг или в фирмвари или драйвере или некое гремучее сочетание первого и второго.
Драйвер контроллера встроен в кернел, а утилита "для железа" от 3вари вроде называется 3dm, к ней есть дока как пользоваться. Перед тем как обращатся в суппорт неплохо знать что данная утилита говорит о состоянии массива.
в release-notes инфы действительно немного, тем не менее там есть ссылка на редхат-багзиллу в котором вероятно можно посмотреть подробности бага "слишком большой лун с непонятным номером". Важен факт что есть упонинание о похожей проблеме, что это вызвано багом, и следствие что все это изветсно в 3вари. Т.к. суза 10
довольно известная ось, скороее всего можно от суппорта услышать нечто толковое.
ПС: не думаю что это массив или контроллер, скорее всего баг или в фирмвари или драйвере или некое гремучее сочетание первого и второго.
-
- Junior member
- Сообщения: 6
- Зарегистрирован: 17 апр 2006, 12:49
-
- Junior member
- Сообщения: 6
- Зарегистрирован: 17 апр 2006, 12:49
Здравствуйте, это опять я.
Сейчас сервак проапргейдили, пока вели работы, установил 9.3.0.3-9500s-Upgrade.zip
В итоге имею:
Monitor BL9x 2.02.00.001
Firmware FE9x 2.08.00.006
Bios BE9x 2.03.01.052
PCB assm Rev 019
Achip 3.20
Pchip 1.50
И ещё имею всё те же проблемы с LUN'ами.
Читал где-то раньше, что проблемы возникают на машинах с большой памятью. У нас 2G. Но вроде бы это должно было быть исправлено в новом Firmware.
Не поможете?
Сейчас сервак проапргейдили, пока вели работы, установил 9.3.0.3-9500s-Upgrade.zip
В итоге имею:
Monitor BL9x 2.02.00.001
Firmware FE9x 2.08.00.006
Bios BE9x 2.03.01.052
PCB assm Rev 019
Achip 3.20
Pchip 1.50
И ещё имею всё те же проблемы с LUN'ами.
Код: Выделить всё
...
scsi: host 0 channel 0 id 0 lun2092 has a LUN larger than allowed by the host adapter
scsi: host 0 channel 0 id 0 lun 0x0100000007000000 has a LUN larger than currently supported.
scsi: host 0 channel 0 id 0 lun38953 has a LUN larger than allowed by the host adapter
scsi: host 0 channel 0 id 0 lun10284 has a LUN larger than allowed by the host adapter
scsi: host 0 channel 0 id 0 lun 0x0100000007000000 has a LUN larger than currently supported.
scsi: host 0 channel 0 id 0 lun41513 has a LUN larger than allowed by the host adapter
scsi: host 0 channel 0 id 0 lun18476 has a LUN larger than allowed by the host adapter
scsi: host 0 channel 0 id 0 lun 0x0100000007000000 has a LUN larger than currently supported.
scsi: host 0 channel 0 id 0 lun44073 has a LUN larger than allowed by the host adapter
scsi: host 0 channel 0 id 0 lun26668 has a LUN larger than allowed by the host adapter
scsi: host 0 channel 0 id 0 lun 0x0100000007000000 has a LUN larger than currently supported.
scsi: host 0 channel 0 id 0 lun46633 has a LUN larger than allowed by the host adapter
scsi: host 0 channel 0 id 0 lun49196 has a LUN larger than allowed by the host adapter
scsi: host 0 channel 0 id 0 lun 0x0100000007000000 has a LUN larger than currently supported.
...
Не поможете?
Может это поможет искать...
Присмотритесь: "lun 0x64652d636f72652e" - это ж шестнадцатеричное представление куска текстовой строки "de-core.", и остальные строчки аналогично, и никакого отношения к реальной конфигурации иметь не может. Похоже, рабочая область программы чем-то перекрывается..., или память барахлит.
Присмотритесь: "lun 0x64652d636f72652e" - это ж шестнадцатеричное представление куска текстовой строки "de-core.", и остальные строчки аналогично, и никакого отношения к реальной конфигурации иметь не может. Похоже, рабочая область программы чем-то перекрывается..., или память барахлит.
-
- Junior member
- Сообщения: 6
- Зарегистрирован: 17 апр 2006, 12:49
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 75 гостей