У меня есть Infortrend A16U-G2421 (LUN 6.3 терабайта, raid5+spare, файловая система ext3). Подключен он через LSI 20320-R (отключен raid, на счет модели в последнее время предываю в сомнениях, чип LSI53C1030). Работает в качестве файлового архива, в день раздает 400-500 гигабайт, полгода работы в режиме 24x7, полет отличный.
ОС - Linux Debian, ядро актуальное.
Место закончилось и был приобретен еще один аналогичный Infortrend (теперь, понятное дело, A16U-G2421-1).
Устанавливаем в стойку, подключаем к первому массиву (последовательно по SCSI), настраиваем, инициализируем, mkfs. Все увиделось и заработало. Почти.
При одновременно работающих массивах при попытке записи некоторого объема данных (3-5 гигабайт непрерывно) на любой из них этот массив перемонтировался в r/o и сыпал в dmesg ошибками типа
Код: Выделить всё
target0:0:0: FAST-160 WIDE SCSI 320.0 MB/s DT IU QAS PCOMP (6.25 ns, offset 127)
target0:0:1: Beginning Domain Validation
EXT3-fs error (device sda) in ext3_new_blocks: Journal has aborted
target0:0:1: Ending Domain Validation
target0:0:1: FAST-160 WIDE SCSI 320.0 MB/s DT IU QAS PCOMP (6.25 ns, offset 127)
__journal_remove_journal_head: freeing b_frozen_data
ext3_abort called.
EXT3-fs error (device sda): ext3_remount:
Abort forced by user
ext3_abort called.
EXT3-fs error (device sda): ext3_remount: Abort forced by user
Код: Выделить всё
sd 0:0:0:0: SCSI error: return code = 0x000b0000
end_request: I/O error, dev sda, sector 8366493248
Buffer I/O error on device sda, logical block 1045811656
lost page write due to I/O error on sda
Buffer I/O error on device sda, logical block 1045811657
lost page write due to I/O error on sda
Buffer I/O error on device sda, logical block 1045811658
lost page write due to I/O error on sda
....
Долго шаманили с бубном, но в итоге победили проблему заменой кабеля, соединяющего массивы. Полтора часа гоняли туда-сюда данные, все работало. Радостоно решили, что проблема устранена и приготовились открывать шампанское. Однако.
Через день стали переносить реальные данные и столкнулись с теми же граблями. На новый массив спокойно перенесли все необходимые файлы (порядка 3.5 терабайт), однако при записи на старый (пробовали варианты "с нового массива", "с другого носителя") порядка ста гигабайт (уже не пять!) получаем те же внешние симптомы - массив перемонтируется в r/o. В dmesg:
Код: Выделить всё
May 2 00:56:27 localhost kernel: mptbase: ioc0: IOCStatus(0x0043): SCSI Device Not There
May 2 00:56:27 localhost kernel: sd 1:0:0:0: SCSI error: return code = 0x00010000
May 2 00:56:27 localhost kernel: end_request: I/O error, dev sdb, sector 5663423392
....
sdb: rw=0, want=23122118584, limit=13667340288
attempt to access beyond end of device
sdb: rw=0, want=15805571280, limit=13667340288
attempt to access beyond end of device
sdb: rw=0, want=15805571280, limit=13667340288
attempt to access beyond end of device
sdb: rw=0, want=23122118584, limit=13667340288
attempt to access beyond end of device
sdb: rw=0, want=15805571280, limit=13667340288
attempt to access beyond end of device
sdb: rw=0, want=23122118584, limit=13667340288
attempt to access beyond end of device
sdb: rw=0, want=15805571280, limit=13667340288
attempt to access beyond end of device
sdb: rw=0, want=15805571280, limit=13667340288
attempt to access beyond end of device
Попробовали еще раз перенести данные:
Код: Выделить всё
mptscsih: ioc0: attempting task abort! (sc=ded80980)
sd 1:0:0:0:
command: Read(16): 88 00 00 00 00 01 73 10 00 00 00 00 00 08 00 00
mptbase: Initiating ioc0 recovery
mptscsih: ioc0: task abort: SUCCESS (sc=ded80980)
EXT3-fs error (device sdb): ext3_new_block: Allocating block in system zone - blocks from 778174464, length 1
Aborting journal on device sdb.
Что мне делать с этим зоопарком различных ошибок и как заставить все это хозяйство работать как следует?
Может быть кто-то уже сталкивался?