☰

Gerät im MD-RAID ausfallen lassen, wenn ATA nicht mehr reagiert

tag-icon • tag-icon linux raid mdadm io raid6
Gerät im MD-RAID ausfallen lassen, wenn ATA nicht mehr reagiert

Ich hatte geschaffenfünf 1TB HDD-Partitionen( /dev/sda1, /dev/sdb1, /dev/sdc1, /dev/sde1, und /dev/sdf1) in einemRAID 6Array wird unter Ubuntu 14.04 LTS Trusty Tahr /dev/md0verwendet .mdadm

Der Befehl sudo mdadm --detail /dev/md0zeigte alle Laufwerke inaktive Synchronisierung.

Dann habe ich zum Testen eine lange E/A-Blockierung simuliert, /dev/sdbindem ich diese Befehle ausgeführt habe, während /dev/sdb1im Array noch aktiv war:

hdparm --user-master u --security-set-pass deltik /dev/sdb
hdparm --user-master u --security-erase-enhanced deltik /dev/sdb

WARNUNG

VERSUCHEN SIE DIES NICHT MIT DATEN, DIE IHNEN WICHTIG SIND!
Durch diesen ATA-Vorgang habe ich 455681 Inodes beschädigt. Ich gebe meine Nachlässigkeit zu.

Der ATA-Befehl zum sicheren Löschen sollte 188 Minuten lang ausgeführt werden und alle anderen Befehle mindestens ebenso lange blockieren.

Ich hatte erwartet md, das nicht reagierende Laufwerk wie einen richtigen RAID-Controller zu löschen, aber zu meiner Überraschung /dev/md0wurde es ebenfalls blockiert.

mdadm --detail /dev/md0fragt das blockierte Gerät ab, sodass es einfriert und keine Ausgabe macht.

Hier ist das Layout von /proc/mdstatdamals, als ich es nicht verwenden konnte mdadm --detail /dev/md0:

root@node51 [~]# cat /proc/mdstat 
Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10] 
md0 : active raid6 sdf1[5] sda1[0] sdb1[4] sdc1[2] sde1[1]
      2929887744 blocks super 1.2 level 6, 512k chunk, algorithm 2 [5/5] [UUUUU]

unused devices: <none>

Ich habe versucht mdadm /dev/md0 -f /dev/sdb1, ein erzwungenes Scheitern zu erzwingen /dev/sdb1, aber das wurde auch blockiert:

root@node51 [~]# ps aux | awk '{if($8~"D"||$8=="STAT"){print $0}}' 
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      3334  1.2  0.0  42564  1800 ?        D    03:21   3:37 parted -l
root      4957  0.0  0.0  13272   900 ?        D    06:19   0:00 mdadm /dev/md0 -f /dev/sdb1
root      5706  0.0  0.0  13388  1028 ?        D    06:19   0:00 mdadm --detail /dev/md0
root      7541  0.5  0.0      0     0 ?        D    Jul19   6:12 [kworker/u16:2]
root     22420  0.0  0.0  11480   808 ?        D    07:48   0:00 lsblk
root     22796  0.0  0.0   4424   360 pts/13   D+   05:51   0:00 hdparm --user-master u --security-erase-enhanced deltik /dev/sdb
root     23312  0.0  0.0   4292   360 ?        D    05:51   0:00 hdparm -I /dev/sdb
root     23594  0.1  0.0      0     0 ?        D    06:11   0:07 [kworker/u16:1]
root     25205  0.0  0.0  17980   556 ?        D    05:52   0:00 ls --color=auto
root     26008  0.0  0.0  13388  1032 pts/23   D+   06:32   0:00 mdadm --detail /dev/md0
dtkms    29271  0.0  0.2  58336 10412 ?        DN   05:55   0:00 python /usr/share/backintime/common/backintime.py --backup-job
root     32303  0.0  0.0      0     0 ?        D    06:16   0:00 [kworker/u16:0]

UPDATE (21. Juli 2015):Nachdem ich die vollen 188 Minuten gewartet hatte, bis der E/A-Block gelöscht war, verwandelte sich meine Überraschung in Entsetzen, als ich sah, dass mdder vollständig gelöschte Block so behandelt wurde, /dev/sdbals wäre er vollkommen intakt.

Ich dachte, dadurch mdwäre zumindest aufgefallen, dass die Parität nicht übereinstimmte und es dann zu einem Rückgang gekommen wäre /dev/sdb1.

In Panik rannte ich mdadm /dev/md0 -f /dev/sdb1noch einmal los und da die E/A-Blockierung aufgehoben worden war, wurde der Befehl schnell abgeschlossen.

Es gab bereits eine Beschädigung des Dateisystems, da Ein-/Ausgabefehler auftraten. Immer noch in Panik führte ich eine langsame Deinstallation der Datenpartition im RAID-Array durch, da reboot -nfich dachte, es könne nicht schlimmer werden.

Nach einigem Nägelkauen e2fsckan der Partition haben es 455681 Inodes hinein geschafft lost+found.

Ich habe das Array inzwischen neu zusammengesetzt und das Array selbst sieht jetzt gut aus:

root@node51 [~]# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Mon Feb 16 14:34:26 2015
     Raid Level : raid6
     Array Size : 2929887744 (2794.16 GiB 3000.21 GB)
  Used Dev Size : 976629248 (931.39 GiB 1000.07 GB)
   Raid Devices : 5
  Total Devices : 5
    Persistence : Superblock is persistent

    Update Time : Tue Jul 21 00:00:30 2015
          State : active 
 Active Devices : 5
Working Devices : 5
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : box51:0
           UUID : 6b8a654d:59deede9:c66bd472:0ceffc61
         Events : 643541

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       97        1      active sync   /dev/sdg1
       2       8       33        2      active sync   /dev/sdc1
       6       8       17        3      active sync   /dev/sdb1
       5       8      113        4      active sync   /dev/sdh1

Es ist für mich immer noch ein ziemlicher Schock, dass mdes nicht die zwei Schutzlinien gibt, die ich erwartet hatte:

  • Fehler beim Absturz eines Geräts
  • Ein Gerät kann nicht funktionieren, wenn die von ihm zurückgegebenen Daten Müll sind.

Fragen

  1. Warum tritt mdbei nicht reagierendem Laufwerk/nicht reagierender Partition kein Fehler auf?
  2. Kann ich das Laufwerk/die Partition aus dem Array löschen, während das Laufwerk blockiert ist?
  3. Kann ein Timeout konfiguriert werden, sodass mdein Laufwerk, das nicht auf ATA-Befehle reagiert, automatisch ausfällt?
  4. Warum lässt sich mdein Gerät mit ungültigen Daten weiter verwenden?

Antwort1

Deltik, Sie haben die mdFunktionsweise von Linux Software-RAID () falsch verstanden.

mdmacht aus mehreren Geräten oder Partitionen ein virtuelles Blockgerät und weiß nicht, welche Daten Sie zum und vom virtuellen Gerät übertragen.
Sie hofften, dass es Dinge tun könnte, für die es nicht konzipiert war.

Antworten

1. Warum tritt mdbei nicht reagierendem Laufwerk/nicht reagierender Partition kein Fehler auf?

Dies liegt daran, mdhat keine Ahnung, ob

  • das Laufwerk ist mit I/O von etwas beschäftigt, das mdes selbst angefordert hat, oder
  • das Laufwerk wurde aufgrund externer Umstände blockiert, z. B. aufgrund der Fehlerbehebung des Laufwerks selbst oder in Ihrem Fall aufgrund eines ATA Secure Erase.

also mdwerde ich abwarten, was das Laufwerk zurückgibt. Das Laufwerk hat letztendlich keine Lese- oder Schreibfehler zurückgegeben. Wenn ein Lesefehler aufgetreten wäre, mdhätte ich ihn automatisch über die Parität behoben, und wenn ein Schreibfehler aufgetreten wäre, mdwäre das Gerät ausgefallen (siehe Abschnitt „Wiederherstellung“ immdmanpage).

Da weder ein Lese- noch ein Schreibfehler vorlag, mdwurde die Verwendung des Geräts fortgesetzt, nachdem der Kernel auf eine Antwort gewartet hatte.

2. Kann ich das Laufwerk/die Partition aus dem Array löschen, während das Laufwerk blockiert ist?

Nein. Das /dev/md0RAID-Gerät ist gesperrt und kann nicht geändert werden, bis die Sperre aufgehoben wird.

Sie haben das Flag -foder --failan den mdadmModus „Verwalten“ übergeben.
Hier ist eine Übersicht darüber, was das tatsächlich bewirkt:

Dies ist der Quellcode zur Funktionsweise dieser Flagge:

case 'f': /* set faulty */
    /* FIXME check current member */
    if ((sysfd >= 0 && write(sysfd, "faulty", 6) != 6) ||
        (sysfd < 0 && ioctl(fd, SET_DISK_FAULTY,
                rdev))) {
        if (errno == EBUSY)
            busy = 1;
        pr_err("set device faulty failed for %s:  %s\n",
            dv->devname, strerror(errno));
        if (sysfd >= 0)
            close(sysfd);
        goto abort;
    }
    if (sysfd >= 0)
        close(sysfd);
    sysfd = -1;
    count++;
    if (verbose >= 0)
        pr_err("set %s faulty in %s\n",
            dv->devname, devname);
    break;

write(sysfd, "faulty", 6)Beachten Sie , dass es sich beim Aufruf sysfdum eine Variable handelt, die zuvor in der Datei festgelegt wurde:
sysfd = sysfs_open(fd2devnm(fd), dname, "block/dev");

sysfs_open()ist eine Funktion vonDiese Datei:

int sysfs_open(char *devnm, char *devname, char *attr)
{
    char fname[50];
    int fd;

    sprintf(fname, "/sys/block/%s/md/", devnm);
    if (devname) {
        strcat(fname, devname);
        strcat(fname, "/");
    }
    strcat(fname, attr);
    fd = open(fname, O_RDWR);
    if (fd < 0 && errno == EACCES)
        fd = open(fname, O_RDONLY);
    return fd;
}

Wenn Sie den Funktionen folgen, werden Sie feststellen, dass mdadm /dev/md0 -f /dev/sdb1im Wesentlichen Folgendes geschieht:

echo "faulty" > /sys/block/md0/md/dev-sdb1/block/dev

Diese Anfrage wartet und wird nicht sofort ausgeführt, da /dev/md0sie blockiert ist.

3. Kann ein Timeout konfiguriert werden, sodass mdein Laufwerk, das nicht auf ATA-Befehle reagiert, automatisch ausfällt?

Ja. TatsächlichStandardmäßig beträgt das Timeout 30 Sekunden:

root@node51 [~]# cat /sys/block/sdb/device/timeout
30

Das Problem bei Ihrer Annahme war, dass Ihr Laufwerk tatsächlich damit beschäftigt war, einen ATA-Befehl auszuführen (für 188 Minuten), sodass es nicht zu einer Zeitüberschreitung kam.

Einzelheiten hierzu finden Sie imDokumentation zur SCSI-Fehlerbehandlung im Linux-Kernel.

4. Warum kann ich mdein Gerät mit ungültigen Daten weiter verwenden?

Als ATA Secure Erase abgeschlossen war, meldete das Laufwerk keine Probleme (z. B. einen abgebrochenen Befehl) und es mdgab daher keinen Grund zur Annahme, dass ein Problem vorlag.

Darüber hinaus wurde die Partitionstabelle im Arbeitsspeicher des Kernels in Ihrem Fall, in dem Sie Partitionen statt ganzer Festplatten als RAID-Geräte verwendet haben, nicht darüber informiert, dass die Partition auf dem gelöschten Laufwerk nicht mehr vorhanden war, und mdkonnte daher weiterhin auf Ihr Laufwerk zugreifen, /dev/sdb1als wäre nichts schiefgegangen.

Dies ist aus demmdmanpage:

Bereinigung und Nichtübereinstimmungen

Da Speichergeräte jederzeit fehlerhafte Blöcke entwickeln können, ist es sinnvoll, regelmäßig alle Blöcke auf allen Geräten in einem Array zu lesen, um solche fehlerhaften Blöcke frühzeitig zu erkennen. Dieser Prozess wird alsSchrubben.

MD-Arrays können gelöscht werden durch Schreiben vonüberprüfenoderReparaturzur Dateimd/SynchronisierungsaktionimsysfsVerzeichnis für das Gerät.

Wenn Sie einen Scrub anfordern, liest md jeden Block auf jedem Gerät im Array und prüft, ob die Daten konsistent sind. Bei RAID1 und RAID10 bedeutet dies, dass geprüft wird, ob die Kopien identisch sind. Bei RAID4, RAID5 und RAID6 bedeutet dies, dass geprüft wird, ob der Paritätsblock (oder die Blöcke) korrekt ist (sind).

Daraus können wir schließen, dass die Parität normalerweise nicht bei jedem Festplatten-Lesevorgang überprüft wird. (Außerdem würde die Überprüfung der Parität bei jedem Lesevorgang die Leistung stark beeinträchtigen, da dadurch die Anzahl der Transaktionen erhöht würde, die nur zum Abschließen eines Lesevorgangs erforderlich sind, und der Vergleich der Parität mit den gelesenen Daten ausgeführt würde.)

Im Normalbetrieb mdgeht es einfach davon aus, dass die gelesenen Daten gültig sind, wodurch es anfällig ist fürstille Datenbeschädigung. In Ihrem Fall waren die Daten auf der gesamten Festplatte unbemerkt beschädigt, weil Sie sie gelöscht hatten.

Ihr Dateisystem war sich der Beschädigung nicht bewusst. Es traten Eingabe-/Ausgabefehler auf Dateisystemebene auf, weil das Dateisystem nicht verstehen konnte, warum es fehlerhafte Daten hatte.

Um eine unbemerkte Datenbeschädigung zu vermeiden,tue nie wieder, was du getan hast. Zweitens: Erwägen Sie die VerwendungZFS, ein Dateisystem, das sich auf die Datenintegrität konzentriert und stille Datenbeschädigungen erkennt und korrigiert.

verwandte Informationen