Почему команда rsync вызывает внезапное отключение USB RAID1 или раздела ext4?

Вопрос или проблема

У меня есть этот корпус Mediasonic PRORAID 2:

https://mediasonicstore.com/products/mediasonic-proraid-2-bay-sata-hard-drive-enclosure-usb-3-1-gen-2-10gbps-usb-type-c-hur5-su31c

И 2x диска Seagate IronWolf Pro ST16000NE000 16 TB в нем.

Корпус подключен к порту USB 3.2 Gen 2 10Gbps (Type-C) на материнской плате B760 GAMING PLUS WIFI, на задней панели.

Ранее у меня не было проблем, при использовании Linux Mint 20.3, когда диск был подключен к рабочей станции.

Теперь я использую Ubuntu Server 24.04 с ядром 6.8.0-55-generic и перенес массив RAID1 на сервер.


Серьезный симптом: rsync вызывает ошибки ext4 и размонтирование

Каждый раз, когда я запускаю эту команду:

rsync -ahHAXS --numeric-ids --info=progress2 --ignore-existing --delete "$source/" "$destination/"

Диск выходит из строя в течение 90 секунд, с этим ужасным выводом журнала dmesg, который монтируется только для чтения:

[  552.391559] usb 2-3: USB disconnect, device number 2
[  552.391761] xhci_hcd 0000:00:14.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
[  552.391791] xhci_hcd 0000:00:14.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
[  552.391906] sd 8:0:0:0: [sda] tag#13 uas_zap_pending 0 uas-tag 10 inflight: CMD 
[  552.391914] sd 8:0:0:0: [sda] tag#13 CDB: Write(16) 8a 00 00 00 00 05 b8 b0 44 00 00 00 04 00 00 00
[  552.391922] sd 8:0:0:0: [sda] tag#14 uas_zap_pending 0 uas-tag 11 inflight: CMD 
[  552.391926] sd 8:0:0:0: [sda] tag#14 CDB: Write(16) 8a 00 00 00 00 05 b8 b0 48 00 00 00 04 00 00 00
[  552.391946] sd 8:0:0:0: [sda] tag#13 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK cmd_age=0s
[  552.391951] sd 8:0:0:0: [sda] tag#13 CDB: Write(16) 8a 00 00 00 00 05 b8 b0 44 00 00 00 04 00 00 00
[  552.391954] I/O error, dev sda, sector 24573395968 op 0x1:(WRITE) flags 0x4000 phys_seg 128 prio class 0
[  552.391988] sd 8:0:0:0: [sda] tag#14 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK cmd_age=0s
[  552.391992] sd 8:0:0:0: [sda] tag#14 CDB: Write(16) 8a 00 00 00 00 05 b8 b0 48 00 00 00 04 00 00 00
[  552.391995] I/O error, dev sda, sector 24573396992 op 0x1:(WRITE) flags 0x4000 phys_seg 128 prio class 0
[  552.392119] device offline error, dev sda, sector 24573398016 op 0x1:(WRITE) flags 0x4000 phys_seg 128 prio class 0
[  552.392159] device offline error, dev sda, sector 24573399040 op 0x1:(WRITE) flags 0x4000 phys_seg 128 prio class 0
[  552.392177] device offline error, dev sda, sector 24573400064 op 0x1:(WRITE) flags 0x4000 phys_seg 128 prio class 0
[  552.392191] device offline error, dev sda, sector 24573401088 op 0x1:(WRITE) flags 0x4000 phys_seg 128 prio class 0
[  552.392205] device offline error, dev sda, sector 24573402112 op 0x1:(WRITE) flags 0x4000 phys_seg 128 prio class 0
[  552.392219] device offline error, dev sda, sector 24573403136 op 0x1:(WRITE) flags 0x4000 phys_seg 128 prio class 0
[  552.392233] device offline error, dev sda, sector 24573404160 op 0x1:(WRITE) flags 0x4000 phys_seg 128 prio class 0
[  552.392248] device offline error, dev sda, sector 24573405184 op 0x1:(WRITE) flags 0x4000 phys_seg 128 prio class 0
[  552.394705] EXT4-fs warning (device sda): ext4_end_bio:343: I/O error 17 writing to inode 390288158 starting block 3071676288)
[  552.394759] Buffer I/O error on device sda, logical block 3071674368
[  552.394783] Buffer I/O error on device sda, logical block 3071674369
[  552.394793] Buffer I/O error on device sda, logical block 3071674370
[  552.394800] Buffer I/O error on device sda, logical block 3071674371
[  552.394807] Buffer I/O error on device sda, logical block 3071674372
[  552.394813] Buffer I/O error on device sda, logical block 3071674373
[  552.394819] Buffer I/O error on device sda, logical block 3071674374
[  552.394825] Buffer I/O error on device sda, logical block 3071674375
[  552.394832] Buffer I/O error on device sda, logical block 3071674376
[  552.394839] Buffer I/O error on device sda, logical block 3071674377
[  552.396023] EXT4-fs warning (device sda): ext4_end_bio:343: I/O error 17 writing to inode 390288158 starting block 3071678080)
[  552.399522] EXT4-fs warning (device sda): ext4_end_bio:343: I/O error 17 writing to inode 390288158 starting block 3071678451)
[  552.400434] EXT4-fs warning (device sda): ext4_end_bio:343: I/O error 17 writing to inode 390288158 starting block 3071680128)
[  552.400444] EXT4-fs warning (device sda): ext4_end_bio:343: I/O error 17 writing to inode 390288158 starting block 3071680157)
[  552.400448] EXT4-fs warning (device sda): ext4_end_bio:343: I/O error 17 writing to inode 390288158 starting block 3071680165)
[  552.400452] EXT4-fs warning (device sda): ext4_end_bio:343: I/O error 17 writing to inode 390288158 starting block 3071680188)
[  552.400472] EXT4-fs warning (device sda): ext4_end_bio:343: I/O error 17 writing to inode 390288158 starting block 3071680192)
[  552.400479] EXT4-fs warning (device sda): ext4_end_bio:343: I/O error 17 writing to inode 390288158 starting block 3071680198)
[  552.400486] EXT4-fs warning (device sda): ext4_end_bio:343: I/O error 17 writing to inode 390288158 starting block 3071680207)
[  552.592126] Buffer I/O error on dev sda, logical block 3122136277, lost async page write
[  552.592133] Buffer I/O error on dev sda, logical block 3363831812, lost async page write
[  552.592135] Buffer I/O error on dev sda, logical block 3363833050, lost async page write
[  552.592137] Buffer I/O error on dev sda, logical block 3363833051, lost async page write
[  552.592138] Buffer I/O error on dev sda, logical block 3363833052, lost async page write
[  552.592139] Buffer I/O error on dev sda, logical block 3363833053, lost async page write
[  552.592141] Buffer I/O error on dev sda, logical block 3363833054, lost async page write
[  552.592142] Buffer I/O error on dev sda, logical block 3363833055, lost async page write
[  552.592143] Buffer I/O error on dev sda, logical block 3363833056, lost async page write
[  552.592145] Buffer I/O error on dev sda, logical block 3363833057, lost async page write
[  552.592266] Aborting journal on device sda-8.
[  552.592278] JBD2: I/O error when updating journal superblock for sda-8.
[  552.592279] EXT4-fs error (device sda) in ext4_reserve_inode_write:5771: IO failure
[  552.592282] EXT4-fs error (device sda): __ext4_ext_dirty:202: inode #390288160: comm kworker/u48:0: mark_inode_dirty error
[  552.592285] EXT4-fs error (device sda) in ext4_reserve_inode_write:5771: Journal has aborted
[  552.592287] EXT4-fs error (device sda): ext4_convert_unwritten_extents:4875: inode #390288160: comm kworker/u48:0: mark_inode_dirty error
[  552.592289] EXT4-fs error (device sda) in ext4_convert_unwritten_io_end_vec:4914: IO failure
[  552.592290] EXT4-fs (sda): failed to convert unwritten extents to written extents -- potential data loss!  (inode 390288160, error -5)
[  552.592329] EXT4-fs (sda): Delayed block allocation failed for inode 390288160 at logical offset 4096 with max blocks 2048 with error 30
[  552.592334] EXT4-fs (sda): This should not happen!! Data will be lost

[  552.592336] EXT4-fs error (device sda) in ext4_do_writepages:2720: Journal has aborted
[  552.592722] EXT4-fs error (device sda): ext4_journal_check_start:84: comm rsync: Detected aborted journal
[  552.592738] EXT4-fs (sda): I/O error while writing superblock
[  552.592738] audit: type=1400 audit(1742179693.074:126): apparmor="DENIED" operation="open" class="file" profile="rsyslogd" name="/run/systemd/sessions/" pid=1134 comm=72733A6D61696E20513A526567 requested_mask="r" denied_mask="r" fsuid=103 ouid=0
[  552.592739] EXT4-fs (sda): Remounting filesystem read-only
[  552.593265] EXT4-fs (sda): I/O error while writing superblock
[  552.992492] sd 8:0:0:0: [sda] Synchronizing SCSI cache
[  553.117444] sd 8:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[  553.340614] usb 2-3: new SuperSpeed Plus Gen 2x1 USB device number 3 using xhci_hcd
[  553.353881] usb 2-3: New USB device found, idVendor=174c, idProduct=1356, bcdDevice= 1.00
[  553.353895] usb 2-3: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[  553.353900] usb 2-3: Product: ASM1352R-Safe
[  553.353904] usb 2-3: Manufacturer: ASMT
[  553.353908] usb 2-3: SerialNumber: 20200409R5000001
[  553.360146] scsi host9: uas
[  553.393073] scsi 9:0:0:0: Direct-Access     ASMT     ASM1352R-Safe    0    PQ: 0 ANSI: 6
[  553.395472] sd 9:0:0:0: Attached scsi generic sg0 type 0
[  553.423683] sd 9:0:0:0: [sdb] 31251693569 512-byte logical blocks: (16.0 TB/14.6 TiB)
[  553.423694] sd 9:0:0:0: [sdb] 4096-byte physical blocks
[  553.423868] sd 9:0:0:0: [sdb] Write Protect is off
[  553.423873] sd 9:0:0:0: [sdb] Mode Sense: 43 00 00 00
[  553.424141] sd 9:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[  553.449569] sd 9:0:0:0: [sdb] Preferred minimum I/O size 512 bytes not a multiple of physical block size (4096 bytes)
[  553.449578] sd 9:0:0:0: [sdb] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)
[  553.458249] sd 9:0:0:0: [sdb] Attached SCSI disk

Это выглядит очень красным и пугающим.


В конечном итоге мне нужно переместить диски внутрь сервера.

И на нем также есть RAID-контроллер.

Но для этого мне нужно больше оборудования и времени: мне нужен третий диск для зеркалирования RAID-массива, затем переместить диски на новый контроллер и, вероятно, в процессе потребуется их переформатировать, затем переместить данные с резервной копии на вновь созданный RAID1 массив.


Пока я хочу продолжать использовать корпус RAID безопасно и попытаться определить, действительно ли проблема с оборудованием.

Сейчас я запускаю это:

sudo smartctl -t long /dev/sda

Но это займет 24 часа для 16-терабайтного диска, и, возможно, еще 24 часа для другого диска в массиве, если другой диск вообще доступен серверу, а не только корпусу RAID.


Изменения с момента последнего успешного использования

  1. Перенос корпуса с Linux Mint 20.3 на Ubuntu Server 24.04
  2. Переход с гораздо более старой USB-интерфейса на гораздо более быструю USB-интерфейс

“То чувство”

С тех пор, как я переключил корпус диска на порт с более высокой скоростью, кажется, что он летает. У меня было несколько опасное чувство, что “это может перегрузить контроллер корпуса”, и я подозреваю, что это не имеет никакого отношения к интерфейсу USB или дискам, но это посредственный контроллер, который перегружен. И я не могу выяснить, какой именно контроллер используется на самом деле.

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

Кстати, это мои параметры записи в /etc/fstab:

/dev/disk/by-uuid/<UUID> /MOUNT auto nosuid,nodev,nofail 0 0

Что, если я делаю неправильно?

Как изолировать и диагностировать настоящую проблему с таким количеством переменных?

Моя главная цель — безопасно продержаться до следующего цикла обновления через квартал года.

Заранее спасибо тем, кто сможет указать на ошибки или предложить решения!

Ответ или решение

Проблема, с которой вы столкнулись, связана с отключением USB-накопителя в режиме RAID1 при использовании команды rsync, что приводит к ошибкам файловой системы ext4 и размонтированию дисков. Чтобы понять причины и предложить возможные решения, необходимо рассмотреть ряд факторов, влияющих на работу устройств хранения данных в вашей системе.

Теория

На уровне теории основными факторами, которые могут привести к описанным проблемам, являются перегрузка или несовместимость контроллера USB, проблемы с драйверами UAS (USB Attached SCSI) и несовместимость или ошибки в новых версиях ядра Linux. Контроллер вашего Mediasonic PRORAID 2 имеет ограничения по производительности, которые могут быть превышены при одновременном использовании высокой скорости передачи данных, такой как USB 3.2 Gen 2. Это приводит к неожиданному отключению устройства.

Кроме того, новая аппаратная конфигурация, включая переход на Ubuntu Server 24.04 и ядро версии 6.8.0-55-generic, может также внести свою лепту, поскольку изменение дистрибутива и аппаратного интерфейса может вызвать несовместимости в обработке подключенных устройств.

Пример

Возьмем для примера описание проблемы: устройство отключается через 90 секунд после начала работы rsync, при этом вывод dmesg указывает на разрыв соединения USB и каскад последующих ошибок ввода-вывода. Эти ошибки говорят о том, что команда rsync вызывает интенсивные операции записи, что может перегрузить контроллер USB в вашем RAID-корпусе, вызывая его отказ работать стабильно.

Ситуация усугубляется тем, что ваш текущий /etc/fstab имеет параметры, которые не предусматривают стабильную работу при высоких нагрузках. Опция nofail, возможно, и предотвращает прекращение загрузки в случае сбоя, но не решает проблему основных причин сбоя.

Применение

Чтобы минимизировать риск отключения и обеспечить стабильность работы вашего RAID-массива на ближайший квартал, рассмотри следующие шаги:

  1. Замедлите передачу данных: Уменьшение нагрузки на контроллер может решить проблему. Попробуйте запустить rsync с ограничением скорости передачи данных с помощью опции --bwlimit=1000 (или другую подходящую скорость в кБ/с):

    rsync -ahHAXS --numeric-ids --info=progress2 --ignore-existing --delete --bwlimit=1000 "$source/" "$destination/"
  2. Обновление драйверов и ядра: Проверьте, есть ли доступные обновления для вашего ядра или драйверов UAS, которые могут исправить найденные ошибки и улучшить совместимость.

  3. Измените конфигурацию fstab: Добавьте параметры, которые могут защитить файловую систему от ошибок при падении соединения. Например, использование async и auto вместе с nofail может оказаться полезным.

  4. Проверка состояние дисков: Завершите тест smartctl для проверки состояния ваших жестких дисков. Это поможет исключить возможность аппаратных неисправностей.

  5. Аппаратное снижение уровня нагрузки: Если есть возможность, рассмотрите переведении дисков в сервер, что снизит нагрузку на внешний контроллер RAID и позволит использовать возможности внутреннего RAID-контроллера сервера.

Следуя данным рекомендациям, вы сможете не только выявить истинные причины проблем, но и обеспечить более стабильную работу системы. Не оставляйте без внимания также обновления ПО и прошивки устройства, которые могут содержать критически важные исправления.

Оцените материал
Добавить комментарий

Капча загружается...