Ich verwende Ubuntu 22.04 auf einem Rechner mit drei Software-RAIDs unterschiedlicher Größe und Geometrie, von denen zwei (sie heißen md5und md6) sehr groß sind. Aus bestimmten Gründen werden die Festplatten zwischen diesen Arrays gemeinsam genutzt.
Jeden Monat cronwird automatisch eine Neuprüfung der Software-RAID-Arrays gestartet. Aufgrund der gemeinsam genutzten Festplatten kann immer nur eine der drei RAID-Prüfungen gleichzeitig ausgeführt werden, die anderen werden automatisch angehalten. Darüber hinaus läuft die Neuprüfung nur sechs Stunden am Tag, wobei ich nicht weiß, wie der Beginn dieses sechsstündigen Zeitfensters bestimmt wird.
Das gemountete Dateisystem md6fror ein, als die erneute Überprüfung md6am zweiten Tag unterbrochen wurde. Alle Prozesse und Threads mit Lese- und Schreibvorgängen in diesem Dateisystem blieben im „unterbrechungsfreien Schlaf“ hängen. Auch ein erzwungenes Unmounten oder Disassemblieren des Arrays war nicht möglich, sodass ich neu booten musste, um wieder auf meine Daten zugreifen zu können. Abgesehen vom effektiven DOS scheinen keine Daten verloren gegangen zu sein.
Aus dem Protokoll erkenne ich Folgendes: Am ersten Tag wird die Prüfung aller drei Arrays gleichzeitig eingeleitet. Das kleinste Array, md1, gewinnt das Rennen um die erste Prüfung, während md5und md6warten müssen. md1ist in weniger als zehn Minuten fertig und wird dann md6bis zum Ende von Tag 1 fortgesetzt.
Am zweiten Tag md5(nicht am bereits begonnenen !) gewinnt derjenige das Rennen, der überprüft wird. Nach sechs Stunden wird md6die Überprüfung für diesen Tag unterbrochen. , der anscheinend wenige Millisekunden später den Befehl „Laufen“ bekommen hat, beginnt zu laufen, nur um noch in derselben Sekunde, in der er gestartet ist, den 6-Stunden-Stopp zu erhalten.md5md6
Nach diesem superschnellen Start-Stopp der Prüfung md6friert md6ein. Das erste Anzeichen dafür im Protokoll ist eine Warnung, dass ein Versuch, in das Dateisystemjournal zu schreiben, seit mehr als zwei Minuten blockiert ist:
Hier die relevanten Teile des Protokolls („M“ ist der Name der Maschine):
Sep 4 08:23:59 M root: mdcheck start checking /dev/md1
Sep 4 08:23:59 M kernel: [1682166.084604] md: data-check of RAID array md1
Sep 4 08:24:00 M root: mdcheck start checking /dev/md5
Sep 4 08:24:00 M kernel: [1682167.725977] md: delaying data-check of md5 until md1 has finished (they share one or more physical units)
Sep 4 08:24:00 M root: mdcheck start checking /dev/md6
Sep 4 08:24:00 M kernel: [1682167.758063] md: delaying data-check of md6 until md5 has finished (they share one or more physical units)
Sep 4 08:33:23 M kernel: [1682730.686726] md: md1: data-check done.
Sep 4 08:33:23 M kernel: [1682730.697864] md: data-check of RAID array md6
Sep 4 08:33:23 M kernel: [1682730.697864] md: delaying data-check of md5 until md6 has finished (they share one or more physical units)
Sep 4 08:34:01 M root: mdcheck finished checking /dev/md1
Sep 4 14:24:02 M root: pause checking /dev/md5 at 0
Sep 4 14:24:03 M kernel: [1703770.476375] md: md6: data-check interrupted.
Sep 4 14:24:03 M root: pause checking /dev/md6 at 5702160936
Sep 4 14:24:03 M systemd[1]: mdcheck_start.service: Deactivated successfully.
Sep 4 14:24:03 M systemd[1]: mdcheck_start.service: Consumed 1.957s CPU time.
Sep 4 20:03:05 M systemd[1]: mdmonitor-oneshot.service: Deactivated successfully.
Sep 5 07:02:14 M root: mdcheck continue checking /dev/md5 from 0
Sep 5 07:02:14 M kernel: [1763663.944043] md: data-check of RAID array md5
Sep 5 07:02:14 M root: mdcheck continue checking /dev/md6 from 5702160936
Sep 5 07:02:14 M kernel: [1763663.980271] md: delaying data-check of md6 until md5 has finished (they share one or more physical units)
Sep 5 13:02:26 M kernel: [1785276.510597] md: md5: data-check interrupted.
Sep 5 13:02:27 M kernel: [1785276.786479] md: data-check of RAID array md6
Sep 5 13:02:27 M root: pause checking /dev/md5 at 5824508144
Sep 5 13:02:27 M kernel: [1785276.795438] md: md6: data-check interrupted.
Sep 5 13:05:31 M kernel: [1785461.181277] INFO: task jbd2/md6-8:2495 blocked for more than 120 seconds.
Sep 5 13:05:31 M kernel: [1785461.181441] task:jbd2/md6-8 state:D stack: 0 pid: 2495 ppid: 2 flags:0x00004000
Sep 5 13:05:31 M kernel: [1785461.181742] md_write_start.part.0+0x174/0x220
Sep 5 13:05:31 M kernel: [1785461.181753] md_write_start+0x14/0x30
Sep 5 13:05:31 M kernel: [1785461.181781] md_handle_request+0x12d/0x1b0
Sep 5 13:05:31 M kernel: [1785461.181792] md_submit_bio+0x71/0xc0
Sep 5 14:44:14 M systemd[1]: mdmonitor-oneshot.service: Deactivated successfully.
Da sich /die /homeDateisysteme auf nicht betroffenen RAIDs befinden, konnte ich mich nach dem Einfrieren von immer noch anmelden md6. cat /proc/mdstatgab die folgenden Informationen:
Personalities : [raid1] [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid10]
md5 : active raid5 sdd4[1] sdk4[2] sdh4[0] sdl4[4]
11415389184 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
bitmap: 0/29 pages [0KB], 65536KB chunk
md1 : active raid1 sdd3[0] sdk3[1] sdh3[3] sdl3[2]
100596736 blocks super 1.2 [4/4] [UUUU]
md6 : active raid6 sdd2[10] sdk2[9] sdh2[11] sdl2[8] sdg[5] sdf[4] sdb[1] sdc[2] sdi[6] sde[3] sdj[7] sda[0]
117186867200 blocks super 1.2 level 6, 512k chunk, algorithm 2 [12/12] [UUUUUUUUUUUU]
[====>................] check = 24.3% (2851080676/11718686720) finish=95845361544.0min speed=0K/sec
bitmap: 0/88 pages [0KB], 65536KB chunk
Bitte beachten Sie, dass /proc/mdstatdie Position der erneuten Überprüfung in 1-kB-Blöcken mit 2851080676 gleich 5702161352 Sektoren zurückzugeben scheint, was nur 416 Sektoren (weniger als ein Block!) von den 5702160936 entfernt ist, die syslogals Position am Vortag protokolliert wurden. Daher gehe ich von einem Deadlock in der gestarteten und dann sofort wieder gestoppten erneuten Überprüfung aus.
Meine bisherige Lösung bestand darin, die automatische MD RAID-Überprüfung zu deaktivieren.
Antwort1
Möglicherweise liegt bei Ihnen dieser Fehler vor:https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.11/+bug/1942935. Es handelt sich um einen Upstream-Kernel-Fehler, der mit Patches in Linux v5.19 behoben wird.
AusKommentar 10können Sie diesen Workaround versuchen (wechseln Sie zuerst md1zu md5/ md6/etc.):
echo active | sudo tee /sys/block/md1/md/array_state