%20werden%20im%20Syslog%20Segmentierungsfehler%20gemeldet..png)
Ich habe gerade mit Snapshots in LVM unter Ubuntu 12.10 experimentiert. Ich habe ein logisches Snapshot-Volume von 6,5 GiB erstellt und nach einigen Änderungen am Ursprung beschlossen, den Snapshot wieder einzufügen, um die Änderungen rückgängig zu machen. Alles schien gut zu laufen, aber ich bemerkte mehrere LVM-bezogene Segfault-Meldungen im Syslog.
Eingegebene Befehle:
sudo lvcreate -L6.5G -n backup_snapshot -s /dev/mapper/vg0-backup
# made some miscellaneous writes
sudo lvconvert --merge /dev/vg0/backup_snapshot
sudo umount /snapshot/backup
sudo umount /backup
sudo lvchange -an /dev/vg0/backup
sudo lvchange -ay /dev/vg0/backup
sudo mount /backup
Aus dem Syslog:
Apr 12 04:57:10 bournemouth kernel: [ 5260.813253] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: errors=remount-ro
Apr 12 05:00:11 bournemouth kernel: [ 5441.841401] EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: errors=remount-ro
Apr 12 05:02:00 bournemouth kernel: [ 5551.438487] show_signal_msg: 48 callbacks suppressed
Apr 12 05:02:00 bournemouth kernel: [ 5551.438495] lvm[5813]: segfault at 28 ip 000000000047f319 sp 00007fff60873de0 error 4 in lvm[400000+d9000]
Apr 12 05:02:01 bournemouth kernel: [ 5552.458797] lvchange[6449]: segfault at 28 ip 000000000047f319 sp 00007fff935f4380 error 4 in lvm[400000+d9000]
Ich habe dann das ursprüngliche LV ausgehängt, sichergestellt, dass der Snapshot nicht mehr existierte, und fsck.ext4 -fes ausgeführt; so war alles in Ordnung. Aber ich mache mir immer noch Sorgen wegen der Segmentierungsfehler. Ist es möglich, dass meine Daten auf eine Weise durcheinander geraten sind, die fsck nicht erkennen konnte? Das Volume, mit dem ich experimentiert habe, war ein Backup-Volume, und alle Dateisysteme, die ich darauf gesichert habe, funktionieren noch, also könnte ich einfach von vorne beginnen und sie erneut sichern. Aber andererseits möchte ich meinen inkrementellen Backup-Verlauf behalten. Ich möchte einfach die Gewissheit, dass ich diesen Backups vertrauen kann.
Antwort1
Ja, es handelt sich definitiv um einen Fehler, aber keine Sorge, LVM ist intelligent genug, um mit diesem Zeug umzugehen. Bei mir ist einmal mitten in einem Pvmove der Strom ausgefallen und alles, was ich tun musste, war im Grunde, den Server wieder einzuschalten, den alten Pvmove „abzubrechen“ und noch einmal von vorne zu beginnen.
Zunächst einmal ist es wichtig zu wissen, dass die von Ihnen verwendeten Tools nur eine Benutzerschnittstelle zu Kernelprozessen sind. LVM befindet sich innerhalb des Kernels, also ist alles in Ordnung, es sei denn, Ihr Kernel gerät in Panik. Die Benutzerschnittstellentools wie pvmove oder lvchange kommunizieren für uns nur mit LVM und lehnen sich dann einfach zurück und fragen den Kernel im Grunde: „Hey, bist du damit schon fertig? Wie ist es gelaufen?“ oder „Hey, wie weit sind wir damit?“ (Ihr spezielles Problem ist, dass lvchange nach erfolgreichem Abschluss einen Segmentierungsfehler verursacht.klingt nach einem kürzlich behobenen FehlerSie sollten daher sicherstellen, dass Sie über alle Systemupdates verfügen.)
Generell sollten Sie auch nicht so ängstlich oder paranoid sein, wenn Sie Probleme mit LVM haben. LVM ist so konzipiert, dass es unerwartete Fehler wie diese gut handhaben kann (selbst wenn sie es direkt betreffen und nicht nur das von Ihnen verwendete Tool) und diese Garantie ist ein Teil des Grunds, warum Sie einen Volume-Manager anstelle von herkömmlichen Partitionen verwenden. Sie haben nur dann Probleme, wenn etwasWirklichEs passiert etwas Schlimmes oder Sie tun etwas, ohne es gründlich zu durchdenken. LVM arbeitet mit Extents (anstatt mit Blöcken) und macht den kopierten Extent erst aktiv und den ursprünglichen inaktiv, wenn der Kopiervorgang bereits erfolgreich abgeschlossen ist. Auf diese Weise bleiben halb kopierte Extents als nicht zugeordnet markiert und alle nachfolgenden Tools überschreiben sie einfach. Dies ist bei meinem pvmove und bei Ihrem lvchange der Fall.
BEARBEITEN:
Anschauendiese Mailinglisten-Ankündigungkönnen wir eine detailliertere Beschreibung erhalten, wie Ihre Zusammenführung tatsächlich „unter der Haube“ funktioniert:
Während die Zusammenführung aktiv ist, werden alle Zugriffe auf das Ursprungsgerät auf den Snapshot umgeleitet, der zusammengeführt wird. Wenn die Zusammenführung abgeschlossen ist, wird das Ursprungsziel nahtlos neu geladen und der zusammengeführte Snapshot gelöscht. Das [Nicht-Snapshot-]Dateisystem kann während dieser Zeit gemountet bleiben.
Dachte, es könnte interessant sein zu wissen
Antwort2
Während die Schwerlastaufgaben vom Kernel (Device Mapper) erledigt werden, sollten Ihre Daten als solche sicher sein. Die LVM-Userland-Tools haben jedoch weiterhin wichtige Funktionen. Sie speichern die LVM-Metadaten, also das, was, wo und wie gespeichert wird, was der Device Mapper selbst weder kennt noch interessiert.
Wenn das LVM-Tool während der Aktualisierung solcher Metadaten einen Segmentierungsfehler verursacht, kann es zu Datenverlust kommen. In gewisser Weise ist LVM ein Dateisystem für Partitionen; beschädigte LVM-Metadaten würden dem Verlust eines Dateisystem-Superblocks gleichkommen. Aus diesem Grund wird fast jede Änderung protokolliert/gesichert /etc/lvm/....
Segfaults sind nie gut – wenn Ihre LVM-Tools dies tun, sollten Sie sie nicht mehr verwenden und zu einer LVM-Version wechseln, die für Sie stabil funktioniert. Und melden Sie den Fehler wahrscheinlich an Ihre Distribution, damit das Problem aufgespürt und endgültig behoben werden kann.