ext4: "Unexpected inconsistency" nach Vergrößerung

[s24!]

Guten Abend,

ich bin etwas verwundert. VMs, die via LVM alle ein eigenes Blockdevice erhalten, vergrößere ich auf triviale Art und Weise: Runterfahren, Logical Volume vergrößern, Partition des Dateisystems mit parted entfernen und in neuer Größe wieder anlegen, resize2fs und VM wieder booten. Hat immer geklappt - bis heute (siehe Bild 1); jetzt macht fsck beim Booten Alarm.

In der Maintenance Shell lässt sich das Ganze auch völlig stressfrei fixen (Bild 2), aber zwei Dinge bleiben mir unklar:

1) Warum kommt es überhaupt zu dem inkonsistenten Zustand? resize2fs auf dem Host spuckte keinerlei Fehler aus.
2) Wenn ich auf dem Host einen fsck ausführe, meldet dieser - egal zu welchem Zeitpunkt - keinerlei Fehler. Auch repariert er nichts, wenn man den --force-Parameter nutzt. Trotzdem meint die VM selber, ihr ext4 sei kaputt (was ja gemäß Ausgabe auch nicht falsch zu sein scheint)...

Ideen? Auch, wenn das offenbar kein größeres Problem ist, ist mir etwas unwohl bei der Sache - denn so eine Inkonsistenz sollte an sich ja nicht durch Vergrößerung des Filesystems auftreten. War ja bislang auch nie der Fall, ist jetzt aber dauerhaft reproduzierbar.


Grüße
Tim

 

[Firewire2002]

Reproduzierbar? Vor dem vergrößern mal ein fsck gemacht?
Beim vergrößern wird der Bereich nicht genullt. Wärs vielleicht möglich, dass in diesem Speicherbereich vorher schon mal ein anderes ext4 lag?

 

[s24!]

Danke für die Antwort!

Reproduzierbar ist es problemlos (jedes Mal). fsck ist vor resize2fs sowieso Pflicht, er lässt einen sonst gar nicht vergrößern; das wurde also auch durchgeführt.

Also im gleichen Logical Volume lag definitiv noch kein ext4. Oder was meinst du?

 

[Firewire2002]

Beispiel:
Du hast 2 gleichgroße LVs hintereinander liegen. Beide haben Daten im ext4 liegen.
Du löschst das hintere LV und machst das erste LV größer. Nun siehst du die Daten vom alten nicht mehr existenten LV im ersten LV.

 

[s24!]

Nein, das ist hier definitiv nicht der Fall (meine hierfür aufgesetzte Test-VM hat aktuell gar kein LV hinter sich). Außerdem: Sicher, dass das funktioniert? Ich wäre eigentlich davon ausgegangen, dass LVM da schon vernünftig abschottet. Und ob man unbedingt in deinem Beispiel den physikalischen Platz des hinteren LVs bekommt? LVM ist ja gerade dafür da, flexibel zu sein, daher kann man ja auch ein LV aus der Mitte problemlos vergrößern.

 

[Firewire2002]

LVM nullt den Speicherbereich nicht. Entsprechend könntest du Teile anderer alter Dateisysteme an der Stelle plötzlich "sehen". Wo das LV liegt ist doch völlig egal. Die technische Möglichkeit, das es in einen bereits vorher schon mal genutzten Speicherbereich hinein wächst, besteht quasi immer.
Ob das konkret bei dir der Fall ist, weiß hier doch keiner. Woher auch. Wir können nur mutmaßen.

Unterscheiden sich vielleicht die ext-Tools zwischen Gast und Host? Unterschiedliche Versionen könnten auch solches Verhalten verursachen. Vielleicht im Gast mittlerweile eine aktuellere Distri drin oder auf dem Host mal Updates eingespielt?

 

[s24!]

Tatsache, ext4 scheint da anderweitige Daten gefunden zu haben. Wieder was dazugelernt. Die wichtigste Frage wäre dann natürlich, ob das ein ernsthaftes Problem ist, oder ob der fsck das im Zweifelsfall vollständig in Ordnung bringt. Ich will ja keine "fremden" Dateien (oder Teile davon) im Dateisystem der VM haben, aber das dürfte meinem Verständnis nach nicht passieren - sie landen ja nicht im "Index" des Dateisystems, nur weil sie physikalisch noch irgendwo rumliegen.

Unterscheiden sich vielleicht die ext-Tools zwischen Gast und Host? Unterschiedliche Versionen könnten auch solches Verhalten verursachen. Vielleicht im Gast mittlerweile eine aktuellere Distri drin oder auf dem Host mal Updates eingespielt?

Ja; das eine ist ein CentOS 6.5, das andere ein Debian Wheezy. Aber inkonsistent ist doch inkonsistent - unabhängig von der Versionsnummer?

 

[elias5000]

Nun siehst du die Daten vom alten nicht mehr existenten LV im ersten LV.

Aber nicht die Meta-Daten. Das Formatieren ohne Löschen der Datenbereiche (aka Schnellformatieren) ist ja durchaus üblich und das Vergrößern einer Partition ist auch nicht viel anders. Selbst das simple Löschen einer Datei löscht nur die Meta-Daten.
Dass in unbelegten Datenbereichen irgendwelche Fragmente rumschwirren ist also eher Normalzustand. Dein Tipp mit den unterschiedlichen Versionen von Host und Gast klingt da schon plausibler.
Wenn da ein fsck Daten der zweiten Partition findet, dann weil er über die Metadaten der hinteren Partition stolpert, die aber verwaist sind.