ubuntuusers.de

mdcheck hängt, Prozess bei 100% CPU, lässt sich nicht stoppen

Status: Ungelöst | Ubuntu-Version: Ubuntu 20.04 (Focal Fossa)
Antworten |

pzYsTorM

Anmeldungsdatum:
9. Dezember 2016

Beiträge: 9

Hallo, habt ihr einen Tipp für mich, was ich tun kann? Mein Server läuft seit vielen Monaten ohne Reboot und ohne Probleme mit einem RAID 6 (über mdadm). Jetzt war ich gerade vier Wochen auf Dienstreise und komme zurück und stelle fest, dass er im mdcheck festhängt:

md2 : active raid6 sdf1[4] sde1[0] sdd1[2] sdc1[1]
      23437503488 blocks super 1.2 level 6, 512k chunk, algorithm 2 [4/4] [UUUU]
      [>....................]  check =  0.4% (57280764/11718751744) finish=104312727.8min speed=1K/sec
      bitmap: 0/88 pages [0KB], 65536KB chunk

md2 ist jedoch noch gemountet und ich kann auf die Daten noch problemlos zugreifen, schreibend und lesend.

Wenn ich mit smartctl die Werte der Festplatte abfrage, sind sdc sdd und sde komplett fehlerfrei, sdf zeigt ein paar Fehler. Alle im "PASSED" Status.

Die Befehle

echo frozen > /sys/block/md2/md/sync_action

oder

echo idle > /sys/block/md2/md/sync_action

klappen alle nicht, da bleibt er hängen und ich kann dann nur mit CTRL+C abbrechen.

Hier ein paar Werte vom Array:

$ cat /sys/block/md2/md/degraded
0
$ cat /sys/block/md2/md/array_state
write-pending

top sagt:

top - 22:36:00 up 227 days, 22:12,  3 users,  load average: 9,00, 9,00, 9,00
Tasks: 198 gesamt,   2 laufend, 196 schlafend,   0 gestoppt,   0 Zombie
%CPU(s):  0,7 be, 12,7 sy,  0,0 ni, 86,6 un,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Spch :  32117,4 gesamt,   4698,5 frei,   2721,3 belegt,  24697,5 Puff/Cache
MiB Swap:      0,0 gesamt,      0,0 frei,      0,0 belegt.  28930,6 verfü Spch

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL
   2101 root      20   0       0      0      0 R 100,0   0,0  52028:06 md2_raid6

Es gibt leider keine syslog logfiles mehr, weil diese nach 7 Tagen bereits gelöscht werden. Der Prozess ist jedoch am 5. Mai schon hängen geblieben.

frostschutz

Avatar von frostschutz

Anmeldungsdatum:
18. November 2010

Beiträge: 7744

In der Regel ist das schlicht und ergreifend - ein Kernel-Bug. Davon gibt es gerade bei md leider ziemlich viele.

sdf zeigt ein paar Fehler. Alle im "PASSED" Status.

Der overall-health self-assessment ist leider ziemlich nichtssagend. Da steht auch bei klinisch toten Platten oft noch PASSED dran.

Wenn die Platte Uncorrectable, Pending, Reallocated Sectors hat, mal über ein mdadm --replace nachdenken. Aber wenn das md schon im check hängt, wird auch kein Rebuild durchlaufen.

Neustarten und hoffen, daß es sich nicht nochmal verschluckt, oder mit einem anderen Kernel probieren.

pzYsTorM

(Themenstarter)

Anmeldungsdatum:
9. Dezember 2016

Beiträge: 9

Oh, super, da bin ich schon mal etwas beruhigter ☺

Sprich: in dem aktuellen Zustand ist es safe einfach mal "reboot" zu tippen? Und wenn er sich beim Reboot wieder hängt, dann hilft wohl nur ein Reset? Ich könnte ja vorher nochmal ein unmount des Arrays versuchen, sodass das Filesystem zumindest clean bleibt.

Kernel update ist auch ein gutes Stichwort. Bin noch bei 5.4.0-165 und könnte zumindest auf 5.4.0-182.

smartctl im Detail für sdf sieht so aus:

Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   016    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   132   132   054    Pre-fail  Offline      -       96
  3 Spin_Up_Time            0x0007   100   100   024    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       4
  5 Reallocated_Sector_Ct   0x0033   100   100   005    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   140   140   020    Pre-fail  Offline      -       15
  9 Power_On_Hours          0x0012   096   096   000    Old_age   Always       -       28081
 10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       4
 22 Helium_Level            0x0023   100   100   025    Pre-fail  Always       -       100
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       1161
193 Load_Cycle_Count        0x0012   100   100   000    Old_age   Always       -       1161
194 Temperature_Celsius     0x0002   193   193   000    Old_age   Always       -       31 (Min/Max 20/37)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       4

Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 4 occurred at disk power-on lifetime: 1 hours (0 days + 1 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 43 00 00 00 00 00  Error: ICRC, ABRT at LBA = 0x00000000 = 0

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  61 00 30 28 50 b9 40 08      01:03:56.880  WRITE FPDMA QUEUED
  61 00 38 28 5a b9 40 08      01:03:56.870  WRITE FPDMA QUEUED
  61 00 28 28 46 b9 40 08      01:03:56.864  WRITE FPDMA QUEUED
  61 00 20 28 3c b9 40 08      01:03:56.849  WRITE FPDMA QUEUED
  61 00 18 28 32 b9 40 08      01:03:56.849  WRITE FPDMA QUEUED

Bei diesen WRITE FPDMA QUEUED Fehlern kenne ich mich nicht genug aus. Deutet das schon auf einen Defekt hin?

encbladexp Team-Icon

Ehemaliger
Avatar von encbladexp

Anmeldungsdatum:
16. Februar 2007

Beiträge: 17518

Dateisysteme haben heute Journaling, die überleben das schon. Hilfreich wäre es mal die SMART Daten aller Platten zu sehen.

frostschutz

Avatar von frostschutz

Anmeldungsdatum:
18. November 2010

Beiträge: 7744

pzYsTorM schrieb:

Bei diesen WRITE FPDMA QUEUED Fehlern kenne ich mich nicht genug aus. Deutet das schon auf einen Defekt hin?

Das sieht nach einem Kabelproblem aus aber der Logeintrag ist uralt... wenn ich daran (und dem UDMA CRC Error Count) nichts ändert, sind die Werte in Ordnung.

Gelegentlich Selbsttests (-t long oder scheibchenweise mit -t select) und gut.

Selbst wenn die Platte defekt wäre, dürfte der Kernelprozess nicht hängen bleiben. Das sind einfach Bugs die bei md leider regelmäßig auftreten.

Antworten |