Рейтинг:0

20.04.2 locks up completely when writing to RAID 6 array

флаг ar

I can reproduce the problem consistently (and in minutes quickly) but I can't find any messages in the logs that are helpful. This problem occurred with a RocketRaid 3740C HBA and the proprietary nvidia driver but now occurs with an LSI/Broadcom 9305-16i HBA and nouveau drivers. I have flashed the Broadcom card to the latest firmware and bios. The Host Bus Adapter is connected to 9 drives (of 10, RAID 6 is degraded until the replacement disk arrives). The network card is a Mellanox ConnectX3 running a 10G ethernet on fibre. Before I exchange the RocketRaid card I remember seeing the proprietary driver write to the kernel log talk about getting 20 something when expecting 18 before the crash. I can't seem to find those messages anymore though (pointers on how to find them appreciated!).

Steps to Reproduce:

Write a lot of things to disk (write speeds are > 700MB/s). For example open 3 scp sessions from another computer and write 3 files in parallel at ~250MB/s each. In less than five minutes Ubuntu screen is frozen / locked up and ssh is non-responsive. Hard reset appears to be the only option. After which mdadm thinks the array is dirty (even though the Event count is the same on all drives). mdadm assemble --force works but then the array spends a day re-syncing.

I'm about at my wits end with this. I'm considering seeing what will happen with TrueNAS or Alma Linux. I'm somewhat wondering about the motherboard too (ASRock Tachi X570). The system seems to be fine under any load that does not involve extensive writes to the array including cpu (5700x) and intense network traffic (I can repeatedly send/receive 10s of Gigabytes of network traffic and get ~70 Gbit/s bandwidth).

Edit per comment from @heynnema

$ sudo free -h
              total        used        free      shared  buff/cache   available
Mem:           62Gi        12Gi       442Mi       372Mi        50Gi        49Gi
Swap:         975Mi        44Mi       931Mi
sudo sysctl vm.swappiness 
vm.swappiness = 60
phil@omni:~$ sudo dmidecode -s bios-version
P4.30
Tasks: 428 total,   2 running, 426 sleeping,   0 stopped,   0 zombie
%Cpu(s): 34.8 us,  2.0 sy,  0.0 ni, 61.1 id,  0.0 wa,  0.0 hi,  2.0 si,  0.0 st
MiB Mem :  64242.9 total,   1192.4 free,  14388.3 used,  48662.3 buff/cache
MiB Swap:    976.0 total,    915.5 free,     60.5 used.  48780.6 avail Mem 

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                                                                                                                  
  15919 fooo      20   0 4083880   3.6g  12520 S 312.5   5.7  77:36.68 chia                                                                                                                                                                     
  15560 fooo      20   0 4083904   3.6g  12544 S  93.8   5.7  77:43.99 chia                                                                                                                                                                     
   4764 root      20   0       0      0      0 S  18.8   0.0  93:17.25 md0_raid6                                                                                                                                                                
   1375 unifi     20   0 4028748 180588  21888 S   6.2   0.3   0:04.47 launcher                                                                                                                                                                 
   2154 unifi     20   0 1078716 132904  39776 S   6.2   0.2   0:25.11 mongod                                                                                                                                                                   
   4776 root      20   0       0      0      0 R   6.2   0.0  18:39.73 md0_resync                                                                                                                                                               
  15419 root      20   0       0      0      0 I   6.2   0.0   0:01.07 kworker/0:1-events                                                                                                                                                       
      1 root      20   0  168296  11728   7896 S   0.0   0.0   0:01.02 systemd                                                                                                                                                                  
      2 root      20   0       0      0      0 S   0.0   0.0   0:00.01 kthreadd                                                                                                                                                                 
      3 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 rcu_gp                                                                                                                                                                   
      4 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 rcu_par_gp                                                                                                                                                               
      6 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker/0:0H-kblockd                                                                                                                                                     
      9 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 mm_percpu_wq                                                                                                                                                             
     10 root      20   0       0      0      0 S   0.0   0.0   0:06.43 ksoftirqd/0                                                                                                                                                              
     11 root      20   0       0      0      0 I   0.0   0.0   0:04.24 rcu_sched                                                                                                                                                                
     12 root      rt   0       0      0      0 S   0.0   0.0   0:00.02 migration/0                                                                                                                                                              
     13 root     -51   0       0      0      0 S   0.0   0.0   0:00.00 idle_inject/0 
cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/vgubuntu-root /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=3C3E-4180  /boot/efi       vfat    umask=0077      0       1
/dev/mapper/vgubuntu-swap_1 none            swap    sw              0       0
#192.168.1.192:/storage     /storage  nfs  defaults 0 0 
UUID=ddc550d2-7f93-4ecf-ac2e-d754c5eee6c9 /storage xfs defaults 0 0 
UUID=BCB65C49B65C05F4 /var/ExChia1 ntfs defaults 0 0
UUID=3A10-3FE7 /var/ExChia4 exfat defaults 0 0
UUID=0EF0-7586 /var/ExChia5 exfat defaults 0 0 
UUID=3837-E26A /var/ExChia6 exfat defaults 0 0
UUID=73338b75-d356-4e7f-9757-948f1078f04e /var/ExChia13 xfs defaults 0 0
heynnema avatar
флаг ru
Отредактируйте свой вопрос и покажите мне `free -h` и `sysctl vm.swappiness` и `sudo dmidecode -s bios-version` и `top`. Начинайте комментировать меня с @heynnema или я пропущу их.
liels avatar
флаг ar
@heynnema, редактируется по запросу.
heynnema avatar
флаг ru
Спасибо за информацию. Покажи мне `кот /etc/fstab`. Вы когда-нибудь запускали memtest на этой конфигурации? Какой у вас загрузочный/системный диск?
liels avatar
флаг ar
@heynnema, fstab выше. Загрузочный/системный диск представляет собой 1 ТБ NVMe firecuda 510. Сейчас работает memtest. Хорошая мысль (много лет назад я использовал новые сборки с набором для обнаружения аппаратных ошибок, который VAlinux написал для своих систем; либо аппаратное обеспечение лучше, либо я ленивее, либо и то, и другое).
heynnema avatar
флаг ru
Есть ли у вас место для маневра, чтобы увеличить раздел подкачки /dev/mapper/vgubuntu-swap_1 или переключиться на /swapfile?
liels avatar
флаг ar
@heynnema да, я могу немного увеличить размер файла подкачки. Без перенастройки оборудования я, вероятно, мог бы сделать, может быть, 300 или 400 ГБ или рекомендованные ранее 2xRAM или 128 ГБ в этом случае. Что ты порекомендуешь? Если нехватка ОЗУ вызывает зависание, я был бы готов купить еще одну пару модулей DIMM и перейти на полные 128 ГБ. FWIW memtester обрабатывает 30G бывшей в употреблении памяти и пока все в порядке.
heynnema avatar
флаг ru
Обмен на 4G. У вас нет файла подкачки, у вас есть раздел подкачки. Вам придется использовать команды LVM для выполнения этой работы. Кроме того, вы знаете, как установить vm.swappiness=10?
liels avatar
флаг ar
@heynnema. Хорошо, я думаю, что понимаю вашу гипотезу о том, что может пойти не так. swappiness теперь равен 10, а vfs_cache_pressure — 100 (вероятно, это то, что нам нужно). lvresize трусливо не позволяет мне возиться с смонтированной корневой файловой системой; Я буду работать с загрузкой USB, сделаю это завтра, после завершения повторной синхронизации, запущу Memtest86+, а затем снова протестирую запись RAID.
heynnema avatar
флаг ru
В работающей системе вы можете отключить подкачку с помощью команды swapoff -a, затем использовать lvresize для расширения /dev/mapper/vgubuntu-swap_1 до 4G, затем `swapon -a`.
liels avatar
флаг ar
@heynnema. К сожалению, это не решило проблему. С swappiness в 10 и 4 ГБ пространства подкачки я смог успешно выполнить один scp со скоростью 250 МБ / с (около 100 ГБ передачи). Своп не использовался. Я сделал 2 успешно (~ 500 МБ / с), и объем подкачки увеличился до 512 байт или около того. Я собирался попробовать 3 потока, думая, может быть, вы решили это. Машина зависла, обрабатывая 2 потока, когда я собирался запустить третий. На тот момент подкачка составляла около 1536 байт. Массив повторно синхронизируется >.<.я перенесу некоторые процессы с этой машины и запущу memtest86, посмотрим, что произойдет.>
heynnema avatar
флаг ru
Разве мы не запускали memtest ранее в этом процессе? Покажи мне `swapon -s`. Вы можете оставить vm.swappiness равным 10. Верните vfs_cache_pressure значение по умолчанию.
liels avatar
флаг ar
@heynnema Да, я запускал memtester для свободной на тот момент памяти ($sudo memtester 30G 3), которая прошла, но не memtest86+ на всех 64Gb. Мне нужно переместить некоторые процессы в другую систему, прежде чем я отключу «эту» на длительный период. Тем временем я запускаю memtester 50G 10).
heynnema avatar
флаг ru
`memtest` следует запускать в автономном режиме при загрузке с флэш-памяти `memtest` USB. Что такое мемтестер? Также покажите мне `swapon -s`. Перейдите на https://www.memtest86.com/ и загрузите/запустите их бесплатный memtest, чтобы проверить свою память. Получите хотя бы один полный проход всех тестов 4/4, чтобы подтвердить хорошую память. Это может занять много часов.
liels avatar
флаг ar
@heynnema. Да я так понимаю, что memtest86+ нужно делать из бут. Я считаю, что он включен в образ 20.04.2 по умолчанию, так что это был мой план, когда я смогу отключить систему. ```` судо свопон -с Имя файла Тип Размер Используемый Приоритет /dev/dm-1 раздел 4194300 2665216 -2 ````
liels avatar
флаг ar
@heynnema, memtest86+ 4 прохода/0 ошибок. Повторно синхронизировано. xfs_repair. Перешел с портов hba на mobo SATA (+2 порта на карте Syba/JM535). Все диски проходят smartctl -t. Запись и чтение 136 ГБ /dev/zero и в /dev/null с синхронизацией. Блокирует секунды после записи со скоростью около 185 МБ / с на одном scp. Еще одна точка данных: другая машина с 20.04.2 сделала то же самое, записав в RAID-0 с двумя дисками nvme, которые были стабильны до и после создания рейда дисков nvme. Я начинаю сильно подозревать, что что-то не так с кодом рейда и/или взаимодействием с xfs. Следующим могу попробовать Рокки или Альму.
heynnema avatar
флаг ru
Можете ли вы загрузиться в Ubuntu Live 21.04 и снова протестировать запись на диски?
liels avatar
флаг ar
@heynnema, кажется, он отлично работает под 21.04 в прямом эфире. Я загрузил в массив около терабайта со скоростью 700-800 МБ/с и никаких признаков проблем. Должна быть проблема с рейдом или кодом xfs или чем-то еще в 20.04.2. Я полагаю, что на данный момент наименее болезненным является обновление до этой версии и ожидание 22.04 LTS. Сообщение об ошибке происходит с ubuntu-bug, в данном случае с ядром для 20.04.2, верно?
heynnema avatar
флаг ru
Хорошие новости! Так ты собираешься обновиться до 21.04, да?
liels avatar
флаг ar
@heynnema. Обновление до 20.10 происходит сейчас. Далее перейдем на 21.04.
Рейтинг:0
флаг es

Итак, у меня была точно такая же проблема, как у вас.

Программная настройка RAID6 на 11 дисков через mdadm с разделом XFS. Диски подключены через комбинацию портов Mobo SATA и Broadcom HBA SATA.

В Ubuntu 20.04.3 LTS у меня было полное зависание системы всякий раз, когда у меня была достаточно высокая пропускная способность для записи в течение достаточно короткого периода времени.

Чтобы исключить любые другие устройства или проблемы с сетью, я обнаружил запись ненужного файла объемом 1 ТБ в массив через dd if=/dev/zero of=testfile bs=1024 count=1024000000 status=progress чтобы быть самым надежным способом воспроизвести проблему.

Решение состояло в том, чтобы перейти на Ubuntu 21.10.. Ubuntu 21.04 зависала немного дольше, но все же зависла. В Ubuntu 21.10 я без проблем выполнил полный тестовый файл объемом 1 ТБ 3 раза. Независимо от того, какая ошибка вызывала это, наконец-то исправлена.

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.