mdadm clean, resyncing

Hast Du Probleme mit Hardware, die durch die anderen Foren nicht abgedeckt werden? Schau auch in den "Tipps und Tricks"-Bereich.
Antworten
tuxedo
Beiträge: 62
Registriert: 26.11.2014 17:03:45
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: CH

mdadm clean, resyncing

Beitrag von tuxedo » 05.08.2018 10:02:00

Hallo zusammen

Ausgangslage ist ein System mit Debian buster/sid, Kernel

Code: Alles auswählen

Linux $HOSTNAME 4.17.0-1-amd64 #1 SMP Debian 4.17.8-1 (2018-07-20) x86_64 GNU/Linux
Das System ist mit drei Platten ausgestattet, alle über SATA Port angeschlossen:
  • sda: SSD (System)
  • sdb/sdc: klassische HDD, 2TB (Daten, bzw. /home/)
Zustand gemäss SMART von allen Platten i.O, auch keine Hänger im Betrieb zu erkennen.

Über sdb1/sdc1 ist ein RAID1 angelegt.

Ab und an (genauers bin ich noch am tracken, vermutlich aber nach einem Reboot) wechselt das RAID in den Zustand

Code: Alles auswählen

State : clean, resyncing 
Ich habe die Vermutung dass folgender syslog Eintrag damit zusammenhängen könnte:

Code: Alles auswählen

Jul 23 17:35:28 $HOSTNAME kernel: [    1.549878] md/raid1:md0: not clean -- starting background reconstruction
Jul 23 17:35:28 $HOSTNAME kernel: [    1.549879] md/raid1:md0: active with 2 out of 2 mirrors
Jul 23 17:35:28 $HOSTNAME kernel: [    1.549979] md0: bitmap file is out of date (49886 < 49887) -- forcing full recovery
Jul 23 17:35:28 $HOSTNAME kernel: [    1.549995] md0: bitmap file is out of date, doing full recovery
Was ich bereits versucht habe:
  • SATA Ports neu gesteckt
  • Komplettes RAID neu gebaut, neu jetzt mit Version 1.2, das alte war noch 0.x
Nach dem Rebuild ist wieder alles i.O, das Raid läuft und macht auch keine Macken bis halt zum nächsten Vorfall.

Folgende Vermutungen habe ich, aber weiss nicht wo ich ansetzten soll:
  • Was periodisches was diesen resync anstösst, nur was triggert den? Ich hatte erst checkarray (via) cron in Verdacht, aber wenn der läuft ist der Status auf "Check Status : xx% complete" und nicht auf resyncing und es gibt entsprechende Logeinträge die ich aber nirgends finde in der Vergangenheit ($HOSTNAME kernel: [ 4562.911095] md: data-check of RAID array md0)
  • Probleme beim Herunterfahren dass das RAID dann zu diesem "bitmap file is out of date" bringt. Nur wie grenzt man sowas ein?
Das Problem verfolgt mich nun schon seit einiger Zeit, leider brachten Suchen im Internet keine Ergebnisse was ähnliche Fälle betrifft.

Gerne nehme ich Ideen und Anregungen entgegen :)

Vielen Dank & Grüsse

tuxedo
Beiträge: 62
Registriert: 26.11.2014 17:03:45
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: CH

Re: mdadm clean, resyncing

Beitrag von tuxedo » 10.08.2018 10:02:44

Hallo zusammen

Heute war es mal wieder soweit:

Code: Alles auswählen

$ cat /proc/mdstat

md0 : active raid1 sdb1[0] sdc1[2]
      1953382464 blocks super 1.2 [2/2] [UU]
      [>....................]  resync =  0.4% (8135104/1953382464) finish=248.6min speed=130394K/sec
      bitmap: 15/15 pages [60KB], 65536KB chunk

Code: Alles auswählen

# /sbin/mdadm -D /dev/md0

/dev/md0:
           Version : 1.2
     Creation Time : Wed May 16 00:35:33 2018
        Raid Level : raid1
        Array Size : 1953382464 (1862.89 GiB 2000.26 GB)
     Used Dev Size : 1953382464 (1862.89 GiB 2000.26 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Fri Aug 10 10:00:47 2018
             State : clean, resyncing 
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : bitmap

     Resync Status : 2% complete

              Name : $HOSTNAME:0  (local to host $HOSTNAME)
              UUID : xyzxyzxy:xyzxyzxy:xyzxyzxy:xyzxyzxy
            Events : 65777

    Number   Major   Minor   RaidDevice State
       0       8       17        0      active sync   /dev/sdb1
       2       8       33        1      active sync   /dev/sdc1
Gestern Abend noch am Rechner gearbeitet und normal heruntergefahren.
Im syslog von heute steht wieder:

Code: Alles auswählen

Aug 10 09:53:54 $HOSTNAME kernel: [    1.588649] md0: bitmap file is out of date (65496 < 65497) -- forcing full recovery
Aug 10 09:53:54 $HOSTNAME kernel: [    1.588690] md0: bitmap file is out of date, doing full recovery
Ich bin ratlos :roll:

Danke & Grüsse

tuxedo
Beiträge: 62
Registriert: 26.11.2014 17:03:45
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: CH

Re: mdadm clean, resyncing

Beitrag von tuxedo » 02.09.2018 18:28:13

Hallo zusammen

Auch heute wieder, inzwischen auf teils neuer Hardware (neues Mainboard, CPU, RAM) wieder das selbe.
Erneut im syslog:

Code: Alles auswählen

Sep  2 17:23:16 neptun kernel: [    2.111343] md0: bitmap file is out of date (110165 < 110166) -- forcing full recovery
Sep  2 17:23:16 neptun kernel: [    2.111396] md0: bitmap file is out of date, doing full recovery
immerhin läuft auf dem neuen Board das Recovery schneller.. :?

Code: Alles auswählen

$ cat /proc/mdstat 
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] 
md0 : active raid1 sdb1[0] sdc1[2]
      1953382464 blocks super 1.2 [2/2] [UU]
      [==>..................]  resync = 14.2% (278606656/1953382464) finish=240.4min speed=116090K/sec
      bitmap: 13/15 pages [52KB], 65536KB chunk

unused devices: <none>
Bin mal die linux-raid Mailingliste durchgegangen, aber da konnte ich nichts ähnliches finden. Was mir etwas Lichtblick verschafft ist dass ich offenbar doch nicht der einzige bin [1]
Grund ist gut möglich, ich habe mounts übers Netzwerk, aber gleich wie bei dem Problem ebenfalls nicht auf Mountpoints die innerhalb des RAIDs liegen würden.

Nur wie debuggt man sowas beim System herunterfahren ob da alles sauber ausgehängt wird? Ich bin auf die Netzwerkmounts angewiesen, daher kann ich die nicht verwenden - evtl. kann ich das gemäss [2] debuggen?
Aber gemäss ersten tests wird diese Ausgabedatei nie erzeugt (auch musste ich unter debian das Verzeichnis system-shutdown/ erst anlegen.)

[1] https://unix.stackexchange.com/question ... ng-my-raid
[2] https://freedesktop.org/wiki/Software/s ... /#index2h1

Danke & Grüsse

Benutzeravatar
Tintom
Moderator
Beiträge: 3029
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: mdadm clean, resyncing

Beitrag von Tintom » 02.09.2018 19:51:45

Hast du es auf der Mailingliste schon probiert? Alternativ zum debuggen: Ein umount beim Netzwerk-FS per Hand durchführen?

Benutzeravatar
whisper
Beiträge: 3156
Registriert: 23.09.2002 14:32:21
Lizenz eigener Beiträge: GNU Free Documentation License
Kontaktdaten:

Re: mdadm clean, resyncing

Beitrag von whisper » 02.09.2018 21:59:32

Ist es wöchentlich?
Das ist ein Cronjob, mach dir keine Sorgen, kein Fehler, sondern ein Check

Benutzeravatar
Tintom
Moderator
Beiträge: 3029
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: mdadm clean, resyncing

Beitrag von Tintom » 02.09.2018 22:53:41

whisper hat geschrieben: ↑ zum Beitrag ↑
02.09.2018 21:59:32
Ist es wöchentlich?
Das ist ein Cronjob, mach dir keine Sorgen, kein Fehler, sondern ein Check
Meinst du den Cronjob in /etc/cron.d/mdadm?

Benutzeravatar
whisper
Beiträge: 3156
Registriert: 23.09.2002 14:32:21
Lizenz eigener Beiträge: GNU Free Documentation License
Kontaktdaten:

Re: mdadm clean, resyncing

Beitrag von whisper » 03.09.2018 08:09:23

Ja, Checkarray
Auf meinem Server ist das immer Sonntaags gewesen

tuxedo
Beiträge: 62
Registriert: 26.11.2014 17:03:45
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: CH

Re: mdadm clean, resyncing

Beitrag von tuxedo » 03.09.2018 08:30:00

Hallo zusammen

Danke für eure Antworten
whisper hat geschrieben: ↑ zum Beitrag ↑
02.09.2018 21:59:32
Ist es wöchentlich?
Das ist ein Cronjob, mach dir keine Sorgen, kein Fehler, sondern ein Check
Siehe unten, ich denke es ist mit hoher Wahrscheinlichkeit nicht der reguläre Check.
Tintom hat geschrieben: ↑ zum Beitrag ↑
02.09.2018 19:51:45
Hast du es auf der Mailingliste schon probiert? Alternativ zum debuggen: Ein umount beim Netzwerk-FS per Hand durchführen?
Bis jetzt habe ich es noch nicht auf der Mailingliste versucht, aber gestern mal angemeldet. Unmount manuell muss man halt immer daran denken, es passiert ja auch nicht jedes mal.
Leider blicke ich bis heute nicht ganz durch den systemd Wald hindurch wo ich da ansetzten müsste um ein manuellen unmount ziemlich früh im Shutdown Ablauf zu verankern.
Auch das mit dem Debuggen vom Shutdown hat mir bis heute keine Ausgabe geliefert, mein Script unter /usr/lib/systemd/system-shutdown/ wird wohl nie ausgeführt (executable ist gesetzt)
Gemäss [1] habe ich das mal nach /lib/systemd/system-shutdown/ verschoben und werde bei nächster Gelegenheit testen.
Tintom hat geschrieben: ↑ zum Beitrag ↑
02.09.2018 22:53:41
Meinst du den Cronjob in /etc/cron.d/mdadm?
Den hatte ich erst unter Verdacht. Aber habe die aufgerufene Kette mal manuell nachverfolgt, die Logeinträge und der Status vom Sync sehen dann anders aus.
im Log steht dann sowas wie:

Code: Alles auswählen

Sep  3 08:18:14 $HOSTNAME kernel: [62513.722017] md: data-check of RAID array md125
Sep  3 08:18:14  $HOSTNAME kernel: [62513.895456] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
Sep  3 08:18:14  $HOSTNAME kernel: [62513.911016] md: delaying data-check of md127 until md125 has finished (they share one or more physical units)
Sep  3 08:18:15  $HOSTNAME kernel: [62514.239874] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for data-check.
Sep  3 08:18:15  $HOSTNAME kernel: [62514.411776] md: using 128k window, over a total of 1946756564k.
und mdstat sagt dann bei einem check sowas:

Code: Alles auswählen

[>....................]  check =  0.0% (xxx/yyy finish=zzz.zmin speed=116224K/sec
[1] https://bugs.debian.org/cgi-bin/bugrepo ... bug=856031

Danke & Grüsse

tuxedo
Beiträge: 62
Registriert: 26.11.2014 17:03:45
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: CH

Re: mdadm clean, resyncing

Beitrag von tuxedo » 24.09.2018 21:27:28

Hallo zusammen

Heute war es mal wieder soweit, aber dank Logging das letzte Shutdown wo der Fehler potentiell auftrat mit aufgezeichnet. Leider steht da nichts was auf einen Fehler hindeutet. Die letzten Zeilen sind dann

Code: Alles auswählen

[ 1802.756139] systemd-shutdown[1]: Sending SIGKILL to remaining processes...
[ 1802.759982] systemd-shutdown[1]: Unmounting file systems.
[ 1802.762079] systemd-shutdown[1]: Successfully forked off '(sd-remount)' as PID 2916.
[ 1802.762328] [2916]: Remounting '/' read-only in with options 'discard,errors=remount-ro,stripe=32734'.
[ 1802.798243] EXT4-fs (sda1): re-mounted. Opts: discard,errors=remount-ro,stripe=32734
[ 1802.825821] systemd-shutdown[1]: All filesystems unmounted.
[ 1802.826625] systemd-shutdown[1]: Deactivating swaps.
[ 1802.827445] systemd-shutdown[1]: All swaps deactivated.
[ 1802.828237] systemd-shutdown[1]: Detaching loop devices.
[ 1802.829039] systemd-shutdown[1]: device-enumerator: scan all dirs
[ 1802.829053] systemd-shutdown[1]:   device-enumerator: scanning /sys/bus
[ 1802.829071] systemd-shutdown[1]:   device-enumerator: scanning /sys/class
[ 1802.829428] systemd-shutdown[1]: All loop devices detached.
[ 1802.830212] systemd-shutdown[1]: Detaching DM devices.
[ 1802.830992] systemd-shutdown[1]: device-enumerator: scan all dirs
[ 1802.830997] systemd-shutdown[1]:   device-enumerator: scanning /sys/bus
[ 1802.831008] systemd-shutdown[1]:   device-enumerator: scanning /sys/class
[ 1802.831028] systemd-shutdown[1]: All DM devices detached.
[ 1802.831806] systemd-shutdown[1]: All filesystems, swaps, loop devices and DM devices detached.
[ 1802.832673] systemd-shutdown[1]: Successfully forked off '(sd-executor)' as PID 2917.
[ 1802.834800] [2917]: Successfully forked off '(direxec)' as PID 2918.
[ 1802.834876] [2917]: Successfully forked off '(direxec)' as PID 2919.
[ 1802.839781] EXT4-fs (sda1): re-mounted. Opts: discard,errors=remount-ro
[ 1802.840220] [2917]: /lib/systemd/system-shutdown/mdadm.shutdown succeeded.
Auch laufen alle unmounts ohne Fehler durch - so wie es sein soll.

Bei der Suche im Netz bin ich noch auf folgendes Posting [1] gestossen. Da fragt sich ein Alex wie das mit der Bitmap Event Count Abweichung überhaupt auftreten kann - und selbst im Falle eines Crashes eigentlich nicht in einem kompletten Resync enden dürfte. Siehe dann auch die FollowUps auf den Beitrag. Das in dem Thread schon ziemlich auf einem Low-Level.

Ich würde mich wenn hier keiner eine Idee dazu hat mal als nächstes an die mdadm Mailingliste wenden, muss nur schauen ob ich das brauchbar in einem verständlichen Englisch zusammenfassen kann. Halte euch dann gerne auf dem laufenden.

[1] https://www.spinics.net/lists/raid/msg47475.html

Grüsse

Benutzeravatar
whisper
Beiträge: 3156
Registriert: 23.09.2002 14:32:21
Lizenz eigener Beiträge: GNU Free Documentation License
Kontaktdaten:

Re: mdadm clean, resyncing

Beitrag von whisper » 25.09.2018 08:17:37

muss nur schauen ob ich das brauchbar in einem verständlichen Englisch zusammenfassen kann
deepl.com
ist dein Freund, schreib es in deutsch, die Übersetzung versteht jeder English Man. Garantiert.
Nehme ich immer, wenn es etwas komplexeres zu sagen gibt.

tuxedo
Beiträge: 62
Registriert: 26.11.2014 17:03:45
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: CH

Re: mdadm clean, resyncing

Beitrag von tuxedo » 07.04.2020 12:10:36

Hallo zusammen

Gerne möchte ich noch Rückmeldung zum nun wohl definitiv gelösten Problem geben.
Ich konnte auf der linux-raid ML nach einiger Diagnose Hilfe finden, und zwar habe ich auf Anraten von einem RAID Kernel Contributor ein Script erstellt:
"/usr/lib/systemd/system-shutdown/md_debug.sh"

Code: Alles auswählen

#!/bin/bash
mount -o remount,rw /
echo ---- begin ---- >> /root/md_debug.txt
date +%Y_%m_%d-%H_%M >> /root/md_debug.txt
mdadm -D /dev/md* &>> /root/md_debug.txt
mdadm -S /dev/md* &>> /root/md_debug.txt
echo ---- end ---- >> /root/md_debug.txt
mount -o remount,ro /
Ich hätte das Script eigentlich nach /usr/lib/ legen sollen, da wurde es aber bei mir nie ausgeführt.
Er meinte evtl. wegen einer sehr alten Distribution (gut, die Basisinstallation ist auch schon ein paar Jahre alt..)
Vielleicht kommt/kam das Problem auch daher? Keine Ahnung - es ist jetzt auf jeden Fall gelöst!
Ich lass das logging mal noch, für den Fall dass es nochmals kommen sollte, aber es ist jetzt schon länger (seit Sept 2019) Ruhe

Danke nochmals an alle die Tipps gegeben haben! :)
Bleibt gesund, Vielen Dank & Grüsse

Antworten