ubuntuusers.de

Raid Problem

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

flip23

Anmeldungsdatum:
6. Oktober 2020

Beiträge: Zähle...

Hallo zusammen,

vorweg: ich alles andere als ein Linuxexperte und bitte daher um ein wenig Nachsicht.

Vor einiger Zeit bastelte ich mir einen kleinen Dateiserver. Es funktionierte alles und deshalb habe ich mich auch knapp ein Jahr um das System dahinter gar nicht gekümmert. Heute wollte ich mich dann doch mal wieder per ssh aufschalten, was jedoch nicht möglich war. Also an den Server. Hier begrüßten mich schon vor dem Login Writeerrors in Listenform. Login selbst war wahnsinnig langsam mit Fehlermeldung (systemd-logind failed to start session scope connection timed out). Ich nehme an die Writeerrors dürften das eigentliche Problem darstellen (write error on swap device - laut dmesg). Das ich zur Zeit nicht per ssh auf den Server komme, muss ich ein bisschen abtippen...

1
2
3
4
5
6
7
cat /proc/mdstat
md0 : active raid1 nvme1n1p5[0]
      214711296 blocks super 1.2 [2/1] [U_]
      bitmap: 1/2 pages [4KB], 65536KB chunk

md1 : active raid0 nvme1n1p6[0]
      9754624 blocks super 1.2 512k chunks
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
mdadm --detail /dev/md0
/dev/md0:
           Version : 1.2
     Creation Time : ... 2019
        Raid Level : raid1
        Array Size : 214711296 (204.76 GiB 219.86 GB) 
     Used Dev Size : 214711296 (204.76 GiB 219.86 GB)
      Raid Devices : 2
     Total Devices : 1
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Tue Oct  6 20:03:38 2020
             State : clean, degraded
    Active Devices : 1
   Working Devices : 1
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : bitmap

              Name : (none):0
              UUID : e741edff:dfb887f8:6d8890ad:58c59a0a
            Events : 986626

  Number     Major     Minor     RaidDevice  State
     0       259          6          0       active sync   /dev/nvme1n1p5
     -         0          0          1       removed
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
mdadm --detail /dev/md1
/dev/md1:
           Version : 1.2
     Creation Time : ... 2019
        Raid Level : raid0
        Array Size : 9754624 (9.30 GiB 9.99 GB) 
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

       Update Time : Thu Jun 13 02:06:01 2019
             State : clean
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

        Chunk Size : 512K

Consistency Policy : none

              Name : (none):1
              UUID : 21bb171a:648f0ec6:56383315:27ca3ce7
            Events : 0

  Number     Major     Minor     RaidDevice  State
     0       259          7          0       active sync   /dev/nvme1n1p6
     1       259          4          1       active sync

Eigentlich sollte md0 die gespiegelte Systempartition (/) sein und md1 als Raid0 auf den selben Datenträgern sein. Wenn einfach nur eine der Platten (nvme) hin wäre, könnte ich das wahrscheinlich selber wieder hinbasteln, aber das hier verstehe ich absolut nicht. Warum ist in dem einen Raid der eine Datenträger(/dev/nvme1n1p6) und in dem anderen Raid der andere Datenträger(/dev/nvme1n1p5)? Und wie behebe ich das am besten wieder?

Ich bin für jede Hilfe Dankbar.

frostschutz

Avatar von frostschutz

Anmeldungsdatum:
18. November 2010

Beiträge: 7790

Auf md0 ist ein Laufwerk rausgeflogen. mdadm --examine /dev/nvme* wäre nicht schlecht um zu sehen wann genau, sofern das Laufwerk nicht schon komplett tot.

Die genauen Fehlermeldungen wären auch hilfreich. Vielleicht kannst du die Ausgaben auch auf einen USB-Stick schubsen, dann brauchst nicht abtippen.

Eigentlich™ ist der Sinn von RAID ja, daß die Kiste weiterläuft, selbst wenn ein Laufwerk stirbt. Das geht bei dir nicht wegen RAID0 (keine Redundanz) auf md1. Aber md0 sollte eigentlich keine Fehler werfen selbst wenn ein Laufwerk fehlt.

Das ist auch der Nachteil von RAID (wenn man kein Monitoring einrichtet) man bekommt zu spät mit daß man eigentlich was hätte machen sollen ... am Ende ist ein Laufwerk tot und das andere hat keine Daten weil schon vor einem Jahr rausgeflogen...

flip23

(Themenstarter)

Anmeldungsdatum:
6. Oktober 2020

Beiträge: 3

Danke erstmal für die Antwort.

Das hat mich gestern wohl doch alles etwas durcheinander gebracht. /dev/nvme1n1p5 und /dev/nvme1n1p6 liegen ja auf dem selben Datenträger und sind nur die Bezeichnungen der Volumes(?) von LVM und Luks. Diese etwas spontan aus dem Bauch heraus getroffene Entscheidung während der Installation (LVM und Verschlüsselung zu verwenden) hatte ich beinahe verdrängt. Die Swap-Partition auf einem Raid0 schien mir während der Installation ein guter Einfall, war aber wie sich nun zeigt nicht zu Ende gedacht. Das Monitoring vom Raid war durchaus geplant. Das kommt jetzt definitiv nach ganz oben auf die ToDo-Liste. Die Idee mit dem USB-Stick ist gut. Da Samba momentan noch läuft, kann ich mir jedoch das Rumgestöpsel mit dem Stick sparen. Danke für den Denkanstoß.

mdadm --examine /dev/nvme*
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
/dev/nvme1n1:
   MBR Magic : aa55
Partition[0] :    439449602 sectors at         2046 (type 05)
/dev/nvme1n1p1:
   MBR Magic : aa55
Partition[0] :    429684736 sectors at            2 (type fd)
Partition[1] :      9764864 sectors at    429684738 (type 05)
/dev/nvme1n1p5:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : e741edff:dfb887f8:6d8890ad:58c59a0a
           Name : (none):0
  Creation Time : Thu Jun 13 02:05:39 2019
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 429422592 (204.76 GiB 219.86 GB)
     Array Size : 214711296 (204.76 GiB 219.86 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
   Unused Space : before=262056 sectors, after=0 sectors
          State : clean
    Device UUID : a9af764a:cb6b9396:ccb5f0e3:15321469

Internal Bitmap : 8 sectors from superblock
    Update Time : Wed Oct  7 20:46:31 2020
  Bad Block Log : 512 entries available at offset 72 sectors
       Checksum : 164f0bea - correct
         Events : 1001538


   Device Role : Active device 0
   Array State : A. ('A' == active, '.' == missing, 'R' == replacing)
/dev/nvme1n1p6:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 21bb171a:648f0ec6:56383315:27ca3ce7
           Name : (none):1
  Creation Time : Thu Jun 13 02:06:01 2019
     Raid Level : raid0
   Raid Devices : 2

 Avail Dev Size : 9754624 (4.65 GiB 4.99 GB)
    Data Offset : 8192 sectors
   Super Offset : 8 sectors
   Unused Space : before=8104 sectors, after=0 sectors
          State : clean
    Device UUID : 557720b1:7afe0806:6fdfedf1:42551045

    Update Time : Thu Jun 13 02:06:01 2019
  Bad Block Log : 512 entries available at offset 72 sectors
       Checksum : ce3401b5 - correct
         Events : 0

     Chunk Size : 512K

   Device Role : Active device 0
   Array State : AA ('A' == active, '.' == missing, 'R' == replacing)

Kann man aus dem Wert der Update Time den letzten funktionierenden Betrieb ableiten? Während dieser bei /dev/nvme1n1p5 aktuell ist, ist der bei /dev/nvme1n1p6 identisch mit der Creation Time. 😬

Bezüglich weiterer Fehlermeldungen habe ich hier dmesg:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
<-- ganz viele Read-error on swap-device -->
[32227323.258095] Read-error on swap-device (253:3:11163440)
[32227323.258216] Read-error on swap-device (253:3:11163448)
[32227323.258336] Read-error on swap-device (253:3:11163456)
[32227323.258456] Read-error on swap-device (253:3:11163472)
[32227323.324218] Buffer I/O error on dev dm-3, logical block 2434032, async page read
[32229066.107459] miniserv.pl[11156]: segfault at 55da8c0fcad8 ip 000055f101d82030 sp 00007ffebe84a7c0 error 4 in perl[55f101cdb000+15d000]
[32229066.107476] Code: 86 01 00 00 48 8b 52 10 49 89 f7 41 89 cc 48 8d 04 c2 4c 8b 30 48 89 44 24 20 4d 85 f6 0f 84 93 00 00 00 4c 89 f3 0f 1f 40 00 <48> 8b 6b 08 44 39 65 00 75 76 4c 63 6d 04 4d 39 cd 75 6d 48 83 c5
[32232669.813596] miniserv.pl[11369]: segfault at 55da8c0fcad8 ip 000055f101d82030 sp 00007ffebe84a7c0 error 4 in perl[55f101cdb000+15d000]
[32232669.813613] Code: 86 01 00 00 48 8b 52 10 49 89 f7 41 89 cc 48 8d 04 c2 4c 8b 30 48 89 44 24 20 4d 85 f6 0f 84 93 00 00 00 4c 89 f3 0f 1f 40 00 <48> 8b 6b 08 44 39 65 00 75 76 4c 63 6d 04 4d 39 cd 75 6d 48 83 c5
[32236273.457514] miniserv.pl[11833]: segfault at 55da8c0fcad8 ip 000055f101d82030 sp 00007ffebe84a7c0 error 4 in perl[55f101cdb000+15d000]
[32236273.457528] Code: 86 01 00 00 48 8b 52 10 49 89 f7 41 89 cc 48 8d 04 c2 4c 8b 30 48 89 44 24 20 4d 85 f6 0f 84 93 00 00 00 4c 89 f3 0f 1f 40 00 <48> 8b 6b 08 44 39 65 00 75 76 4c 63 6d 04 4d 39 cd 75 6d 48 83 c5
[32239877.168312] miniserv.pl[12061]: segfault at 55da8c0fcad8 ip 000055f101d82030 sp 00007ffebe84a7c0 error 4 in perl[55f101cdb000+15d000]
[32239877.168326] Code: 86 01 00 00 48 8b 52 10 49 89 f7 41 89 cc 48 8d 04 c2 4c 8b 30 48 89 44 24 20 4d 85 f6 0f 84 93 00 00 00 4c 89 f3 0f 1f 40 00 <48> 8b 6b 08 44 39 65 00 75 76 4c 63 6d 04 4d 39 cd 75 6d 48 83 c5

Und was mir nun beinahe mehr Kopfzerbrechen als das Raid macht, ist das scheinbar mit Systemd etwas nicht stimmt. systemctl-Befehle beispielsweise enden immer mit einem Timeout

Failed to list units: Failed to activate service 'org.freedesktop.systemd1': timed out (service_start_timeout=25000ms)

Was mache ich denn am besten als nächstes? Gleich eine neue Nvme bestellen?

frostschutz

Avatar von frostschutz

Anmeldungsdatum:
18. November 2010

Beiträge: 7790

Also das zweite nvme-Laufwerk ist ganz weg?

Sofern du die Möglichkeit dazu hast, zieh dir mit ddrescue ein Abbild der nvme1n1 auf ein unabhängiges Speichermedium.

ddrescue /dev/nvme1n1 /mnt/extern/nvme1n1.img /mnt/extern/nvme1n1.map

Dann würde ich Swap deaktivieren (stürzt die Kiste womöglich ab bei) und einen Neustart probieren. Falls du das noch nicht getan hast (dein dmesg Timestamp sieht nach >1 Jahr Uptime aus).

Vielleicht taucht dann auch die SSD auf wundersame Weise wieder auf, wenn die nur irgendwie "abgestürzt" ist. Manchmal reparieren sich die Dinge ja von selbst, wenn man nur einmal alles aus- und wieder einschaltet (Neustart als Kaltstart, 1 Minute komplett vom Strom trennen).

Ansonsten wenn es defekt ist dann hilft alles nichts als defekte Teile tauschen. SSDs sind nicht unsterblich...


Falls der Dateizugriff noch normal funktioniert, auch einfach so ein Backup davon.

flip23

(Themenstarter)

Anmeldungsdatum:
6. Oktober 2020

Beiträge: 3

Also den Swap wollte ich gestern schon deaktivieren, hatte ich zwar nicht geschrieben, aber daher weiß ich das die systemctl Befehle einen Timeout bekommen, weil Systemd nicht richtig läuft. Und weil Systemd nicht läuft kann ich offenbar auch keine USB-Geräte mounten (systemd-udevd). Ich vermute das ich mich deswegen auch nicht mehr per ssh aufschalten kann und es bei der Anmeldung direkt am Gerät zu Fehlermeldungen kam (systemd-logind failed to start session scope connection timed out).

Ich befürchte mich hier zu verrennen und tendiere immer mehr zu Plan B: Da das System nur liederlich eingerichtet wurde, ginge bei einer Neuinstallation nichts von Wert verloren. Die eigentlichen Daten des Fileservers, die ich jedoch retten möchte, liegen auf einem dritten, voll funktionsfähigem Raid. Auch dieses Raid habe ich im Wahn mit LVM und Verschlüsselung erstellt. Das wiederum führt mich zur alles entschiedenen Frage: Könnte ich bei einer Neuinstallation dieses Raid "einfach" wieder einbinden und mittels der Passphrase wieder darauf zugreifen?

Bezüglich der vermeintlich defekten nvme bin auch sehr gespannt. Wenn es soweit ist und ich die Kiste runterfahre, werde ich nachdem ich das Gerät Stromlos ist die beiden nvmes ausbauen, kontakte freiblasen und dann schauen wir mal. Apropos herunterfahren, da wird mir Systemd doch auch wieder das Leben schwer machen...

Antworten |