[Eisfair] [e64] rebuild of md0 wird angestoßen wegen "WQ_UNBOUND"

[Nelson Matias]

Hallo Fabian,

am Tue, 8 Apr 2025 16:46:10 +0200 schrieb Fabian in spline.eisfair

> > Ich habe manuell einen Check auf meinem RAID gestartet via
> > echo check > /sys/block/mdX/md/sync_action  
>habe ich auch gemacht:
>eis # echo check > /sys/block/md0/md/sync_action
>eis # cat /proc/mdstat
>Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] 
>[raid4] [multipath]
>md0 : active raid5 sdb1[2] sdc1[1] sda1[4] sdd1[0]
>       11720655360 blocks super 1.2 level 5, 512k chunk, algorithm 2 
>[4/4] [UUUU]
>       [>....................]  check =  0.5% (20582076/3906885120)   
>finish=351.0min speed=184519K/sec
>       bitmap: 0/30 pages [0KB], 65536KB chunk
>
>unused devices: <none>
>eis #
>
>top - 16:33:22 up 11 min,  2 users,  load average: 1.52, 1.06, 0.56
>Tasks: 213 total,   2 running, 211 sleeping,   0 stopped,   0 zombie
>%Cpu(s):  1.0 us, 19.0 sy,  0.0 ni, 77.7 id,  0.0 wa,  0.0 hi,  2.2 si, 
>0.0 st
>MiB Mem : 7822.102 total, 3329.059 free, 2475.043 used, 2128.207 buff/cache
>MiB Swap: 15999.99+total, 15999.99+free,    0.000 used. 5347.059 avail Mem
>
>   PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ 
>COMMAND
>   411 root      20   0       0      0      0 R 31.56 0.000   1:16.30 
>md0_raid5
>  8535 root      20   0       0      0      0 D 10.30 0.000   0:16.42 
>md0_resync
>
>
>bei mir steht auch check - und resync bei top ?!

Ich denke das der check und resync vom gleichen Prozess gemacht werden.
Wenn die Daten passen ists gut, wenn nicht wird die Reparatur versucht.
Einzig bei den mdstats ist das zu unterscheiden.
Das RAID-Event ist aber immer das gleiche, deshalb die verwirrende
Meldung von mdadm und mdmonitor.

>Vielen Dank für die ausführlichen Erklärungen!
>Die einzige Frage die sich mir nun noch stellt ist - warum habe ich 
>diese Meldungen vorher nicht vernommen ?!
>
>Es kann sein, dass es damit zusammenhängt, dass ich mal weil ich (warum 
>auch immer) - zuu viele mdadm Info Mails bekommen habe. (Da war ich mal 
>mit Holger dran) den Schalter von No auf Yes gestellt habe:

Das kann durchaus sein.
Ich bekomme auch immer mal sporadisch Meldungen, das ein Array
verschwunden sei und kurz danach wieder da ist. Bisher ist das immer beim
Check passiert und ich habe das einfach auf eine verlängerte
Reaktionszeit des Arrays geschoben. 

>Was mich wundert ich habe gestern schon wieder so eine Mail bekommen:
>
>Dispatched from mdadm Agent on Server 'eis'
>Current Date: 2025-04-07 Time: 01:07:17
>
>Host            : eis
>MD Device       : /dev/md/0
>Event           : RebuildStarted
>
>/proc/mdstat dump:
>Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] 
>[raid4] [multipath]
>md0 : active raid5 sdb1[2] sdc1[1] sdd1[0] sda1[4] (mismatch_cnt=0) 
>(NOTE: No hotspare?!)
>11720655360 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
>[=================>...]  check = 87.9% (3434357436/3906885120)   
>finish=70.6min speed=111500K/sec
>bitmap: 1/30 pages [4KB], 65536KB chunk
>
>unused devices: <none>
>
>sollte doch m.M. nur einmal im Monat stattfinden oder ?!

Diese folgende Zeile erklärt das:

>MDADM_MD_CHECK_TIME='Sun *-*-1..7 1:00:00'

Es wird für den Check die Zeit 1..7 ( 1 Uhr bis 7 Uhr ) festgelegt. Dein
Check war um 7 Uhr noch nicht abgeschlossen, daher wurde er unterbrochen.
Am Folgetag wird er dann um 1 Uhr an der Stelle wieder fortgesetzt an der
der Check abgebrochen war. 
Falls du den Server bis 9 Uhr nicht nutzt, könntest du die Check-Zeit auf
1..9 erweitern, das sollte eigentlich reichen, wenn die Schätzung vom
RAID stimmt (finish=70.6min). Den Check auf vor Mitternacht zu erweitern
würde ich nicht empfehlen, da um 0 Uhr normal einige Tasks laufen
(logrotate). Oder akzeptieren, das es eben 2 Tage dauert ... bei mir
dauert es 3 Tage bei einem Array ;)

-- 
Gruß

Nelson