So beheben Sie das Problem mit dem Btrfs-Umfang

436
Michael Firth

Ich glaube, ich wurde von einem bekannten Fehler in btrfs betroffen:

https://www.spinics.net/lists/linux-btrfs/msg60984.html

Sicher, die Fehlermeldungen scheinen ähnlich zu sein. Wenn es sich um dasselbe Problem handelt, scheint es etwas unglücklich, dass der Fix für eine zwei Jahre alte Ausgabe nicht in den stabilen V4.9-Kernel portiert wurde (was Debian 9 verwendet).

Ich bin jetzt in der Situation, in der eines der Dateisystem-Inodes Probleme mit dem Umfang hat (wie von gemeldet btrfs check):

root 257 inode 2607184 errors 100, file extent discount Found file extent holes: start: 0, len: 81920

Es scheint, dass es nicht viele Ratschläge oder Unterlagen gibt, wie man aus einer solchen Situation herauskommt (zum Glück habe ich Backups des betroffenen Dateisystems, daher könnte der schlimmste Fall neu formatieren und wiederherstellen).

Es scheint, dass btrfs check --repairnur die gleichen Fehler immer wieder gedruckt werden, ohne dass der Fehler behoben wird.

Gibt es eine Möglichkeit, das vorhandene Dateisystem zu reparieren, oder kann ich es am besten neu erstellen und die Sicherung wiederherstellen?

0
Danke - Ich habe mich für eine ähnliche (aber etwas extremere) Option entschieden, das Sub-Volume mit den Problemen zu löschen. Es scheint, dass die Freigabe des Inodes das Dateisystem sauber gemacht hat. Wenn Sie eine Antwort auf dieser Grundlage erstellen möchten, werde ich sie als richtig bewerten Michael Firth vor 5 Jahren 0

1 Antwort auf die Frage

1
Kamil Maciorowski

Ich denke, root 257bezieht sich auf die Sub-Volume-ID, dann inode 2607184verweist auf den problematischen Inode. Ich würde versuchen, jeden mit dem Inode verknüpften Pfad zu entfernen.

  1. Mounten Sie das Subvolume:

    mount /dev/sdXN -o subvolid=257 /mnt/mountpoint

  2. Finde jeden Eintrag mit passender Inode-Nummer:

    find /mnt/mountpoint -xdev -inum 2607184

  3. Untersuchen Sie die Objekte. Hoffentlich können Sie es sich leisten, sie zu löschen.

    • (Ich bin mir nicht sicher, ob es in Ihrem Fall ein Verzeichnis sein kann). Wenn es sich um ein Verzeichnis handelt, vermute ich, dass die Auflistung unvollständig ist.
      1. Verschieben Sie den Inhalt (falls vorhanden) in ein anderes, neues Verzeichnis (erstellen Sie es mit demselben Besitz, möglicherweise mit Berechtigungen); Entferne das alte Verzeichnis. mvdas neue Verzeichnis auf den alten Namen.
      2. Vergleichen Sie mit Ihrer Sicherung, stellen Sie fehlende Objekte wieder her.
    • Wenn es sich um eine oder mehrere Dateien handelt -
      1. Entferne sie alle.
      2. Stellen Sie die Dateien aus dem Backup wieder her.

  4. Unmount:

    umount /mnt/mountpoint

  5. Überprüfen Sie das Dateisystem. Die problematische Inode sollte nicht mehr sein.

Alternativ können Sie das gesamte Subvolumen löschen. Dies scheint ein Overkill zu sein, sollte jedoch die problematische Inode beseitigen.

  1. Mounten Sie das Stammverzeichnis des Dateisystems:

    mount /dev/sdXN -o subvol=/ /mnt/mountpoint

  2. Liste der Subvolumes:

    btrfs subvolume list /mnt/mountpoint

    und suchen Sie die mit der ID 257.

  3. Löschen Sie das Subvolume:

    btrfs subvolume delete -c /mnt/mountpoint/path/to/the/subvolume/with/ID/257

  4. Unmount:

    umount /mnt/mountpoint

  5. Überprüfen Sie das Dateisystem. Die problematische Inode sollte nicht mehr sein.

  6. Stellen Sie Ihre Daten aus dem Backup wieder her.
Da es sich um neu erstellte Dateien handelt, die den Fehler ausgelöst hatten (eine git-Prüfung), und ich regelmäßig Snapshots für die Verwendung mit Samba erstellt habe, akzeptierte ich schließlich ein Zurückrollen um 20 Minuten und löschte das Subvolume. 'btrfs check' meldet jetzt keine Fehler, hoffentlich liegt keine zugrunde liegende Korruption vor, die später beißen wird Michael Firth vor 5 Jahren 0

Verwandte Probleme