Puncte:0

20.04.2 locks up completely when writing to RAID 6 array

drapel 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
drapel ru
Editează-ți întrebarea și arată-mi `free -h` și `sysctl vm.swappiness` și `sudo dmidecode -s bios-version` și `top`. Începeți-mi comentariile cu @heynnema sau îmi vor lipsi.
liels avatar
drapel ar
@heynnema, editări la cerere.
heynnema avatar
drapel ru
Multumesc pentru informatii. Arată-mi `cat /etc/fstab`. Ați rulat vreodată `memtest` pe această configurație? Care este discul tău de boot/sistem?
liels avatar
drapel ar
@heynnema, fstab este deasupra. Discul de pornire/sistem este un firecuda 510 NVMe de 1TB. Se rulează memtest acum. Gând bun (cu vârste în urmă obișnuiam să ard în versiuni noi cu o suită de detectare a erorilor hardware shakedown pe care VAlinux a scris-o pentru sistemele lor; fie hardware-ul este mai bun, fie sunt mai leneș sau ambele).
heynnema avatar
drapel ru
Aveți spațiu pentru a crește partiția de swap /dev/mapper/vgubuntu-swap_1 sau pentru a trece la un /swapfile?
liels avatar
drapel ar
@heynnema da, pot crește dimensiunea fișierului de swap, cu destul de mult. Fără a rearanja hardware-ul, probabil că aș putea face poate 300 sau 400G sau 2xRAM sau 128G recomandat în acest caz. Ce ai recomanda? Dacă lipsa memoriei RAM cauzează blocarea, aș fi dispus să cumpăr o altă pereche de DIMM-uri și să merg la 128G complet. Memtesterul FWIW procesează 30G de memorie folosită pentru a fi liberă și până acum totul este în regulă.
heynnema avatar
drapel ru
Schimbarea rapidă la 4G. Nu aveți un fișier de swap, aveți o partiție de swap. Va trebui să utilizați comenzi LVM pentru a face treaba. De asemenea, știți cum să setați vm.swappiness=10?
liels avatar
drapel ar
@heynnema. Ok, cred că am înțeles ipoteza ta despre ce ar putea merge prost. Swappiness este acum 10 și vfs_cache_pressure este 100 (care este probabil ceea ce ne dorim). lvresize nu mă lasă laș să mă încurc cu sistemul de fișiere rădăcină montat; Îl voi lucra de la o pornire USB, fă asta mâine după ce se termină resincronizarea, rulează Memtest86+ și apoi testează din nou scrierea RAID.
heynnema avatar
drapel ru
Pe un sistem live, puteți dezactiva schimbarea cu comanda `swapoff -a`, apoi utilizați `lvresize` pentru a extinde /dev/mapper/vgubuntu-swap_1 la 4G, apoi `swapon -a`.
liels avatar
drapel ar
@heynnema. Nu a rezolvat problema din păcate. Cu swappiness la 10 și 4gb de spațiu de swap am reușit să fac un scp la 250MB/s cu succes (aproximativ 100GB de transfer). Schimbul nu a fost folosit. Am făcut 2 cu succes (~ 500 MB/s) și schimbul a ajuns la 512 octeți sau cam asa ceva. Eram pe cale să încerc 3 fluxuri gândindu-mă că poate ai rezolvat-o. Mașina a blocat procesând 2 fluxuri când eram pe punctul de a începe al treilea. Schimbarea era de aproximativ 1536 de octeți în acel moment. Matricea se resincronizează din nou >.<.Voi migra unele procese de pe acea mașină și voi rula memtest86, vedeți ce se întâmplă.>
heynnema avatar
drapel ru
Nu am rulat `memtest` mai devreme în acest proces? Arată-mi `swapon -s`. Puteți lăsa vm.swappiness la 10. Setați vfs_cache_pressure înapoi la valoarea implicită.
liels avatar
drapel ar
@heynnema Da, am rulat memtester pentru memoria care era liberă în acel moment ($sudo memtester 30G 3), care a trecut, dar nu și memtest86+ pe toți cei 64 Gb. Trebuie să mut unele procese într-un alt sistem înainte de a lua „acesta” unul offline pentru o perioadă lungă de timp. Între timp, folosesc memtester 50G 10).
heynnema avatar
drapel ru
`memtest` ar trebui să fie rulat offline, când este pornit pe USB-ul flash `memtest`. Ce este `memtester`? Arată-mi și `swapon -s`. Accesați https://www.memtest86.com/ și descărcați/rulați „memtestul” gratuit pentru a vă testa memoria. Obțineți cel puțin o trecere completă a tuturor testelor 4/4 pentru a confirma o memorie bună. Acest lucru poate dura multe ore.
liels avatar
drapel ar
@heynnema. Da, înțeleg că memtest86+ trebuie făcut din boot. Cred că este inclus în imaginea 20.04.2 în mod implicit, așa că acesta a fost planul meu odată ce pot deconecta sistemul. ```` sudo swapon -s Nume fișier Tip Dimensiune Folosit Prioritate /dev/dm-1 partiție 4194300 2665216 -2 ````
liels avatar
drapel ar
@heynnema, memtest86+ 4 treceri/0-eroare. Resincronizat. xfs_repair. Trecut de la porturile hba la mobo SATA (+2 porturi pe un card Syba / JM535). Toate unitățile trec prin smartctl -t. A scris și citit 136 GB /dev/zero și la /dev/null cu sincronizare. Se blochează secunde după scriere la aproximativ 185 MB/s pe un scp. Un alt punct de date: o altă mașină cu 20.04.2 a făcut același lucru scriind pe un RAID-0 cu două unități nvme care fuseseră stabile înainte și după efectuarea raid-ului unităților nvme. Încep să suspectez cu tărie ceva în neregulă cu codul raid și/sau interacțiunea cu xfs. S-ar putea să încerci apoi Rocky sau Alma.
heynnema avatar
drapel ru
Puteți porni la Ubuntu Live 21.04 și puteți testa din nou scrierea pe discuri?
liels avatar
drapel ar
@heynnema, se pare că funcționează bine sub 21.04 live. Am împins aproximativ un terrabyte pe matrice la 700-800MB/s și niciun semn de probleme. Trebuie să fie o problemă cu codul raid sau xfs sau ceva în 20.04.2. Presupun că cel mai puțin dureros lucru în acest moment este să faceți upgrade la acea versiune și să așteptați 22.04 LTS. Raportarea erorilor se întâmplă cu ubuntu-bug, în acest caz kernel-ul pentru 20.04.2, nu?
heynnema avatar
drapel ru
Vești bune! Deci veți actualiza la 21.04, da?
liels avatar
drapel ar
@heynnema. Actualizarea la 20.10 are loc acum. Se va trece pe 21.04 următoare.
Puncte:0
drapel es

Deci, am avut exact aceeași problemă ca și tine.

11 software de disc RAID6 de configurare prin mdadm cu o partiție XFS. Discuri atașate prin combinație de porturi mobo SATA și broadcom HBA SATA.

Pe Ubuntu 20.04.3 LTS, aveam înghețari complete ale sistemului ori de câte ori aveam scrieri cu lățime de bandă suficient de mare într-o perioadă de timp suficient de scurtă.

Pentru a exclude orice alte dispozitive sau probleme de rețea, am găsit că scriu un fișier nedorit de 1 TB în matrice prin dd if=/dev/zero of=testfile bs=1024 count=1024000000 status=progress pentru a fi cel mai fiabil mod de a reproduce problema.

Soluția a fost să faceți upgrade la Ubuntu 21.10. Ubuntu 21.04 a durat puțin mai mult să se înghețe, dar a rămas înghețat. Pe Ubuntu 21.10 mi-aș putea face întregul fișier de testare de 1 TB de 3 ori fără probleme. Orice eroare a cauzat acest lucru este în sfârșit remediat.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.