Adaptec 6405 firmware update.
Процесс обновления прошивки для RAID контроллера Adaptec 6405.Обнаружилась следующая проблема: при копировании разделов средствами dd, процесс копирования останавливался с ошибкой, а в dmesg были следующие сообщения:
[1963733.948808] aacraid: Host adapter abort request (0,0,0,0)
[1963733.948823] aacraid: Host adapter reset request. SCSI hang ?
[1964808.789967] aacraid: Host adapter abort request (0,0,0,0)
[1964808.789982] aacraid: Host adapter reset request. SCSI hang ?
[1964818.780310] sd 0:0:0:0: [sda] Medium access timeout failure. Offlining disk!
[1964818.780315] sd 0:0:0:0: Device offlined - not ready after error recovery
[1964818.780321] sd 0:0:0:0: [sda] Unhandled error code
[1964818.780323] sd 0:0:0:0: [sda] Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK
[1964818.780327] sd 0:0:0:0: [sda] CDB: Read(10): 28 00 04 68 6f e0 00 00 08 00
[1964818.780336] end_request: I/O error, dev sda, sector 73953248
[1964818.780350] sd 0:0:0:0: rejecting I/O to offline device
[1964818.780357] Buffer I/O error on device dm-0, logical block 456177
[1964818.780360] lost page write due to I/O error on dm-0
[1964818.780366] sd 0:0:0:0: rejecting I/O to offline device
[1964818.780369] Buffer I/O error on device dm-7, logical block 436247
[1964818.780371] lost page write due to I/O error on dm-7
[1964818.780374] Buffer I/O error on device dm-7, logical block 436248
[1964818.780376] lost page write due to I/O error on dm-7
[1964818.780379] Buffer I/O error on device dm-7, logical block 436249
[1964818.780381] lost page write due to I/O error on dm-7
[1964818.780383] Buffer I/O error on device dm-7, logical block 436250
[1964818.780385] lost page write due to I/O error on dm-7
[1964818.780388] Buffer I/O error on device dm-7, logical block 436251
[1964818.780390] lost page write due to I/O error on dm-7
[1964818.780392] Buffer I/O error on device dm-7, logical block 436252
[1964818.780394] lost page write due to I/O error on dm-7
[1964818.780397] Buffer I/O error on device dm-7, logical block 436253
[1964818.780399] lost page write due to I/O error on dm-7
[1964818.780402] Buffer I/O error on device dm-7, logical block 436254
[1964818.780404] lost page write due to I/O error on dm-7
[1964818.780406] Buffer I/O error on device dm-7, logical block 436255
[1964818.780408] lost page write due to I/O error on dm-7
[1964818.780460] sd 0:0:0:0: rejecting I/O to offline device
[1964818.780518] sd 0:0:0:0: rejecting I/O to offline device
[1964818.780575] sd 0:0:0:0: rejecting I/O to offline device
[1964818.780640] sd 0:0:0:0: rejecting I/O to offline device
[1964818.780696] sd 0:0:0:0: rejecting I/O to offline device
[1964818.780752] sd 0:0:0:0: rejecting I/O to offline device
[1964818.780809] sd 0:0:0:0: rejecting I/O to offline device
[1964818.780865] sd 0:0:0:0: rejecting I/O to offline device
[1964818.780929] sd 0:0:0:0: rejecting I/O to offline device
[1964818.780987] sd 0:0:0:0: rejecting I/O to offline device
[1964818.781043] sd 0:0:0:0: rejecting I/O to offline device
[1964818.781100] sd 0:0:0:0: rejecting I/O to offline device
[1964818.781157] sd 0:0:0:0: rejecting I/O to offline device
[1964818.781214] sd 0:0:0:0: rejecting I/O to offline device
[1964818.781270] sd 0:0:0:0: rejecting I/O to offline device
[1964818.781358] Aborting journal on device dm-0.
[1964818.781376] sd 0:0:0:0: rejecting I/O to offline device
[1964818.781384] EXT3-fs (dm-0): error in ext3_reserve_inode_write: Journal has aborted
[1964818.781389] EXT3-fs (dm-0): error in ext3_reserve_inode_write: Journal has aborted
[1964818.781392] JBD: I/O error detected when updating journal superblock for dm-0.
[1964818.781408] sd 0:0:0:0: rejecting I/O to offline device
[1964818.781429] sd 0:0:0:0: rejecting I/O to offline device
[1964818.781439] EXT3-fs (dm-0): I/O error while writing superblock
[1964818.781442] EXT3-fs (dm-0): error in ext3_dirty_inode: Journal has aborted
[1964818.781445] EXT3-fs (dm-0): error in ext3_dirty_inode: Journal has aborted
[1964818.781452] sd 0:0:0:0: rejecting I/O to offline device
[1964818.781458] EXT3-fs (dm-0): I/O error while writing superblock
[1964818.781462] EXT3-fs (dm-0): error: ext3_journal_start_sb: Detected aborted journal
[1964818.781465] sd 0:0:0:0: rejecting I/O to offline device
[1964818.781467] EXT3-fs (dm-0): error: remounting filesystem read-only
[1964818.781470] EXT3-fs (dm-0): I/O error while writing superblock
[1964818.790244] sd 0:0:0:0: rejecting I/O to offline device
[1964818.790358] sd 0:0:0:0: rejecting I/O to offline device
[1964818.790432] sd 0:0:0:0: rejecting I/O to offline device
Весьма неприятные сообщения, вариантом решения было предложено обновить прошивку контроллера. Для прошивки нам понадобится утилита arcconf из пакета storman. Это утилита от самой Adaptec для работы с контроллерами. На сервере установлена arcconf версии 5.20 (B17414) и в ней есть функции обновления контроллеров. Саму прошивку можно достать на сайте производителя.
Для начала смотрим информацию о текущей версии прошивки
# arcconf getconfig 1 ad
Controllers found: 1
----------------------------------------------------------------------
Controller information
----------------------------------------------------------------------
Controller Status : Optimal
Channel description : SAS/SATA
Controller Model : Adaptec 6405
Controller Serial Number : 2B1511EF4B2
Physical Slot : 6
Temperature : 57 C/ 134 F (Normal)
Installed memory : 512 MB
Copyback : Disabled
Background consistency check : Disabled
Automatic Failover : Enabled
Defunct disk drive count : 0
Logical devices/Failed/Degraded : 1/0/0
--------------------------------------------------------
Controller Version Information
--------------------------------------------------------
BIOS : 5.2-0 (18668)
Firmware : 5.2-0 (18668)
Driver : 1.2-0 (28900)
Boot Flash : 5.2-0 (18668)
--------------------------------------------------------
Controller Battery Information
--------------------------------------------------------
Status : Optimal
Over temperature : No
Capacity remaining : 0 percent
Time remaining (at current draw) : 0 days, 0 hours, 0 minutes
Теперь проходим по ссылке, принимаем лицензионное соглашение, скачиваем прошивку и доставляем архив прошивки на сервер. Распаковываем архив.
# unzip 6405_fw_b19076.exe
Теперь запускаем процесс обновления. Обновление длится в течение одной-двух минут после чего сервер следует перезагрузить.
# arcconf romupdate 1 as6405
Controllers found: 1
You must restart the system for firmware updates to take effect.
Are you sure you want to continue?
Press y, then ENTER to continue or press ENTER to abort: y
Updating controller 1 firmware...Succeeded
A new software image has been applied to controller 1.
Command completed successfully.
Переагружаемся, после загрузки смотрим версию прошивки.
# reboot
# arcconf getconfig 1 ad
--------------------------------------------------------
Controller Version Information
--------------------------------------------------------
BIOS : 5.2-0 (19076)
Firmware : 5.2-0 (19076)
Driver : 1.2-0 (28900)
Boot Flash : 5.2-0 (19076)
Как видно версия сменилась с 18668 на 19076. А помогла ли прошивка контроллера покажет время...
На главную "Virtualizing Linux"
Спасибо уже один серв обновил. Правда думаю что с переименованиями бред просто нужно команду писать без 0 в конце arcconf romupdate 1 as6405 и всё
ОтветитьУдалитьХехе, действительно, мне что-то не пришло это в голову. Спасибо за замечание, поправил.
ОтветитьУдалитьи что показало время? :)
ОтветитьУдалитьу меня 6405e так вот при копировании больших файлов (>30 гигов) загрузка процессора максимальная, с чем может быть связано?
Время показало что обновление не особо то и помогло, вероятно проблема вовсе не в контроллере. Брали три сервера у всех одна и та же болезнь, отвал дисковой подсистемы и многочисленные IO Error. С этих пор продукцию Supermicro (в частности X9DRW) я для себя забраковал))))
ОтветитьУдалитьПо данному вопросу может быть масса решений, причем дело здесь не в мат.плате.
ОтветитьУдалитьСмотрите дисковую подсистему, сделайте verify массива (кстати вы его не назвали, как и не назвали модели дисков, но догадываюсь, что массив 5ee, а диски seagate)
Далее проверяйте, что может мешать выполнению вашей команды, к примеру плановые задания (системные возможно).
Спасибо, вопрос уже решен, это было в ноябре 12-го... массив был RAID10, диски да seagate constellation. verify был сделан в самую первую очередь. В итоге емнип мы заменили это контроллеры на LSI'евские и больше не возвращались к этому вопросу. И да, если вы читали коментарии выше, одна и та же проблема была на трех серверах так что все таки склоняюсь что проблема где то на уровне несовместимостей между железками вендоров.
УдалитьЯ не говорю, что проблема не в контроллерах адаптек, как и не исключаю совместимость, хотя это и маловероятно (судя из таблиц на оф.сайтах производителей).
УдалитьНо проблема как, я понимаю, была исключительно на системах Linux на всех 3х серверах. Это вам не показалось странным? как вела себя продукция мелкомягких, или Вы её не используете на них?
пс. ну Вы сами поймите, поменять контроллер - это не лучший выход, особенно в денежном плане. А если бы у Вас было 100 серверов к примеру? не вариант сразу..))
Кстати я тоже не утверждаю что проблема была в контроллерах, а лишь допускаю;).
УдалитьMS мы не использовали по идеологическим причинам. В Linux'е пробовали разные версии ядер (соотв. и драйвера разные). Что по вашему тут странного? Поменять контроллер на трех серверах это, в данном случае нормально. И чтобы такой ситуации не возникло при наличии 20 серверов (на данный момент) мы отбраковали супермикры, сейчас у той конторы стоят DELL'ы R620.
P.S. а о чем вообще дискуссия? :)
В данном случае выяснялись дополнительные нюансы, пусть люди знают, как решить такую проблему, даже таким способом как вы (менять железо). Ведь главное что в итоге проблема решена.
Удалить