Hallo alle, ich habe mir vor kurzem mein System (openSuSE 13.1, rootfs=BTRFS und homefs=BTRFS) durch einen Kernel-Update so zerschossen, dass es nicht mehr startet. Nun dachte ich, ich mache mir Backups etc. und repariere es, klappte bisher aber nicht. Dann dachte ich, ich mache ein System Backup (das unter Yast) via Livesystem und chroot. Selbiges läuft (oder sollte ich sagen schleicht) jetzt seit über 40 Stunden und wird einfach nicht fertig. Ist das normal? Ich denke eigentlich nicht: Unter "/" befinden sich gerade mal ca. 9 GB, mit allerdings knapp 13 Mio. Dateien unter "/.snapshot" und DA ist er immer noch nicht durch :-( Hätte jemand eine Idee, wieso das so lange dauert oder vielleicht sogar, wie ich das System elegant wieder zum Starten bringe? Die Dateisysteme sind nämlich in Ordnung! Übrigens habe ich "/" und "/home" als BTRFS auf zwei Platten verteilt (RAID1) und hatte eigentlich mit "/boot/efi" und den Swap-Partitionen das gleiche vor, leider geht das offenbar nicht: # fdisk -l (von den relevanten Platten) ------------------------------------------------------------------------------------- WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion. Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes, 1953525168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk label type: gpt # Start End Size Type Name 1 2048 321535 156M Microsoft basic primary 2 321536 4530175 2G Linux swap primary 3 4530176 88422399 40G Microsoft basic primary 4 88422400 1953523711 889.4G Microsoft basic primary WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion. Disk /dev/sde: 1000.2 GB, 1000204886016 bytes, 1953525168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk label type: gpt # Start End Size Type Name 1 2048 321535 156M EFI System primary 2 321536 4530175 2G Linux swap primary 3 4530176 88422399 40G Microsoft basic primary 4 88422400 1953523711 889.4G Microsoft basic primary ------------------------------------------------------------------------------------- # btrfs fi show Label: none uuid: d740dd1d-edab-48bf-952b-16926cf0b568 Total devices 2 FS bytes used 36.11GiB devid 1 size 889.35GiB used 42.04GiB path /dev/sde4 devid 2 size 889.35GiB used 42.03GiB path /dev/sdd4 Label: none uuid: 7840498f-e504-466c-8d55-fbec0a1c08e6 Total devices 2 FS bytes used 8.60GiB devid 1 size 40.00GiB used 10.04GiB path /dev/sde3 devid 2 size 40.00GiB used 10.03GiB path /dev/sdd3 Btrfs v0.20-rc1+20130701 ------------------------------------------------------------------------------------- Danke euch -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 29.05.2014 13:34, schrieb Martin Deppe:
Hallo alle,
ich habe mir vor kurzem mein System (openSuSE 13.1, rootfs=BTRFS und homefs=BTRFS) durch einen Kernel-Update so zerschossen, dass es nicht mehr startet ...
Hallo Martin Das wird wahrscheinlich kein allzu hilfreicher Beitrag, aber ich denke, man darf zur Zeit noch vor dem Produktiv-Einsatz von BTRFS warnen. Mir ist nämlich so ziemlich das gleiche passiert, wie Dir: Das ROOTFS war nach dem letzten Kernelupdate _read only_ !?! Dateisystemchecks ergaben ein angeblich konsistentes FS ... ja, und nun? Alle Reparaturversuche brachten keinerlei Fortschritt. Ich habe dann also neu installiert. Und zwar mit dem guten alten ext4. Alles läuft seither prima. -- Mit herzlichen Grüßen, Denis Wollenhaupt --------------------------------------- Göttinger Labor für Genomananlyse Georg-August-Universität Göttingen Grisebachstr. 8 | D-37077 Göttingen Tel: +49 (0) 551 - 20 19 834 http://appmibio.bio.uni-goettingen.de/ --------------------------------------- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 29.05.2014 13:44, schrieb Denis Wollenhaupt:
Am 29.05.2014 13:34, schrieb Martin Deppe:
Hallo alle,
ich habe mir vor kurzem mein System (openSuSE 13.1, rootfs=BTRFS und homefs=BTRFS) durch einen Kernel-Update so zerschossen, dass es nicht mehr startet ...
Hallo Martin
Das wird wahrscheinlich kein allzu hilfreicher Beitrag, aber ich denke, man darf zur Zeit noch vor dem Produktiv-Einsatz von BTRFS warnen.
Mir ist nämlich so ziemlich das gleiche passiert, wie Dir:
Das ROOTFS war nach dem letzten Kernelupdate _read only_ !?!
Dateisystemchecks ergaben ein angeblich konsistentes FS ... ja, und nun?
Alle Reparaturversuche brachten keinerlei Fortschritt.
Ich habe dann also neu installiert. Und zwar mit dem guten alten ext4.
Alles läuft seither prima.
Tja, so ähnlich plane ich es auch schon langsam, mehr und mehr. Ich denke, das Dateisystem ist wohl tatsächlich in Ordnung, ich kann nur nicht 'booten'. Was mich nur äußerst merkwürdig stimmt ist, dass es offenbar knapp 13 Mio. Dateien unter "/.snapshot" gibt. Eine derart große Anzahl habe ich, meine ich, noch nie innerhalb eines Dateisystems gesehen und weiterhin dass das Systembackup soooo lange braucht, bei so "wenig" Daten (9 GB, wie gesagt). -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Thu, 29 May 2014 14:09:31 +0200 schrieb Martin Deppe <Martin.Deppe@web.de>:
Ich denke, das Dateisystem ist wohl tatsächlich in Ordnung, ich kann nur nicht 'booten'. Was mich nur äußerst merkwürdig stimmt ist, dass es offenbar knapp 13 Mio. Dateien unter "/.snapshot" gibt.
Wenn / als btrfs eingerichtet wird, werden zyklisch snapshots angelegt, IIRC stündlich - da kommt schon einiges zusammen. Unter /.snapshot liegen die Metadaten zur Verwaltung der snapshots. Es ist halt eine Eigenheit von btrfs, alle Snapshots samt Metadaten im eigenen Filesystem zu verwalten. An und für sich gehört aber die Fähigkeit, sehr viele Dateien und/oder sehr große Volumen zu verwalten, zu den Eigenschaften, weshalb man modernere Filesysteme wie btrfs überhaupt entwickelt hat. Anschauen kann man sich das mit Werkzeugen wie snapper. Ich nehme an, dass man für Backups eines btrfs-root eigene Backup-Werkzeuge verwendet, die auf snapshots gehen. Normalerweise macht man ja seine Backups im laufenden Betrieb und ohne Reboot von Live-CD. btrfs ist sicher nicht die erste Wahl, wenn es um einfache und stabile Handhabung geht. Die meisten setzen da lieber auf ext4fs oder Vorgänger. Bei RHEL bevorzugt man in jüngerer Zeit XFS. Gruß, Tobias. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo zusammen, Martin Deppe meinte am Donnerstag, den 29.05.2014 um 14:09 Uhr wegen:(BTRFS-)System Backup - die unendliche Geschichte
Am 29.05.2014 13:44, schrieb Denis Wollenhaupt:
Am 29.05.2014 13:34, schrieb Martin Deppe:
Hallo alle,
ich habe mir vor kurzem mein System (openSuSE 13.1, rootfs=BTRFS und homefs=BTRFS) durch einen Kernel-Update so zerschossen, dass es nicht mehr startet ...
Hallo Martin
Das wird wahrscheinlich kein allzu hilfreicher Beitrag, aber ich denke, man darf zur Zeit noch vor dem Produktiv-Einsatz von BTRFS warnen.
Mir ist nämlich so ziemlich das gleiche passiert, wie Dir:
Das ROOTFS war nach dem letzten Kernelupdate _read only_ !?!
Dateisystemchecks ergaben ein angeblich konsistentes FS ... ja, und nun?
Alle Reparaturversuche brachten keinerlei Fortschritt.
Ich habe dann also neu installiert. Und zwar mit dem guten alten ext4.
Alles läuft seither prima.
Tja, so ähnlich plane ich es auch schon langsam, mehr und mehr.
Ich denke, das Dateisystem ist wohl tatsächlich in Ordnung, ich kann nur nicht 'booten'. Was mich nur äußerst merkwürdig stimmt ist, dass es offenbar knapp 13 Mio. Dateien unter "/.snapshot" gibt. Eine derart große Anzahl habe ich, meine ich, noch nie innerhalb eines Dateisystems gesehen und weiterhin dass das Systembackup soooo lange braucht, bei so "wenig" Daten (9 GB, wie gesagt).
ich hatte - als ich btrfs mall getestet habe - ./snapshot vom Backup ausgenommen. Ich hätte auch nicht gewusst, was ich damit hätte tun können. Machte für mich deshalb keinen Sinn. Als totaler Laie setze ich eher auf bewährtes ;) -- Beste Grüße Christian Schade, dass XMMS gerade nichts spielt :( -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Martin, Am 29.05.2014 13:34, schrieb Martin Deppe:
Hallo alle,
ich habe mir vor kurzem mein System (openSuSE 13.1, rootfs=BTRFS und homefs=BTRFS) durch einen Kernel-Update so zerschossen, dass es nicht mehr startet. Nun dachte ich, ich mache mir Backups etc. und repariere es, klappte bisher aber nicht. Na toll, nur gut dass ich vor knapp vier Wochen mich ebenfalls für BTRFS auf dem Notebook entschieden habe (wegen der Snapshots)
Dann dachte ich, ich mache ein System Backup (das unter Yast) via Livesystem und chroot. Selbiges läuft (oder sollte ich sagen schleicht) jetzt seit über 40 Stunden und wird einfach nicht fertig. Ist das normal? Ich denke eigentlich nicht: Unter "/" befinden sich gerade mal ca. 9 GB, mit allerdings knapp 13 Mio. Dateien unter "/.snapshot" und DA ist er immer noch nicht durch :-( Ja, diese .snapshot Verzeichnisse sind schon echt saublöde. Da hat wie ich finde Debian/Ubuntu einen wesentlich besseren Ansatz dafür gemacht (ich hab das auf meiner XBMC/Xbian Distri für den Raspberry so, ne echt coole Sache und läuft bisher völlig problemlos) aber das hilft dir natürlich jetzt auch nicht. Ich für meinen Teil sichere jeden Tag via rsnapshot, wobei ich natürlich die .snapshot Verzeichnisse ausklammere, auf ein anderes System. Auf die Snapshots kann man im Falle eines FS-GAUs eh Verzichten, wie ich meine.
Hätte jemand eine Idee, wieso das so lange dauert oder vielleicht sogar, wie ich das System elegant wieder zum Starten bringe? Die Dateisysteme sind nämlich in Ordnung!
Leider schreibst Du nicht, wie sich das äußert, dass dein System nicht mehr startet.
Übrigens habe ich "/" und "/home" als BTRFS auf zwei Platten verteilt (RAID1) und hatte eigentlich mit "/boot/efi" und den Swap-Partitionen das gleiche vor, leider geht das offenbar nicht: # fdisk -l (von den relevanten Platten) -------------------------------------------------------------------------------------
# btrfs fi show Label: none uuid: d740dd1d-edab-48bf-952b-16926cf0b568 Total devices 2 FS bytes used 36.11GiB devid 1 size 889.35GiB used 42.04GiB path /dev/sde4 devid 2 size 889.35GiB used 42.03GiB path /dev/sdd4
Label: none uuid: 7840498f-e504-466c-8d55-fbec0a1c08e6 Total devices 2 FS bytes used 8.60GiB devid 1 size 40.00GiB used 10.04GiB path /dev/sde3 devid 2 size 40.00GiB used 10.03GiB path /dev/sdd3
Btrfs v0.20-rc1+20130701 ------------------------------------------------------------------------------------- Seltsam, bei mir ist Btrfs v3.12+20131125, ebenfalls openSUSE 13.1 64Bit
Wie du schreibst, sind die beiden FS soweit in Ordnung. Da würde ich halt "ganz einfach" den Snapshot vor dem Kernelupdate verwenden und damit die FS wieder herstellen, dafür sind die Snapshots ja eigentlich ja auch da Gruß Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Kleiner Nachtrag: Am 29.05.2014 17:08, schrieb Manfred Kreisl:
Btrfs v0.20-rc1+20130701 -------------------------------------------------------------------------------------
Seltsam, bei mir ist Btrfs v3.12+20131125, ebenfalls openSUSE 13.1 64Bit
Wie du schreibst, sind die beiden FS soweit in Ordnung. Da würde ich halt "ganz einfach" den Snapshot vor dem Kernelupdate verwenden und damit die FS wieder herstellen, dafür sind die Snapshots ja eigentlich ja auch da Guck dir mal die Seite hier an: http://doc.opensuse.org/products/draft/SLES/SLES-admin_sd_draft/cha.snapper....
insbesondere Procedure 4.2. Undoing changes using the snapper command Ein noch konsistentes FS vorausgesetzt, kann man - zumindest theoretisch - mit einem Befehl - das FS wieder zum jeden beliebigen (Snapshot)Zeitpunkt restaurieren Gruß Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 29.05.2014 17:28, schrieb Manfred Kreisl:
Kleiner Nachtrag:
Am 29.05.2014 17:08, schrieb Manfred Kreisl:
Btrfs v0.20-rc1+20130701 -------------------------------------------------------------------------------------
Seltsam, bei mir ist Btrfs v3.12+20131125, ebenfalls openSUSE 13.1 64Bit
Wie du schreibst, sind die beiden FS soweit in Ordnung. Da würde ich halt "ganz einfach" den Snapshot vor dem Kernelupdate verwenden und damit die FS wieder herstellen, dafür sind die Snapshots ja eigentlich ja auch da Guck dir mal die Seite hier an: http://doc.opensuse.org/products/draft/SLES/SLES-admin_sd_draft/cha.snapper....
insbesondere Procedure 4.2. Undoing changes using the snapper command
Ein noch konsistentes FS vorausgesetzt, kann man - zumindest theoretisch - mit einem Befehl - das FS wieder zum jeden beliebigen (Snapshot)Zeitpunkt restaurieren
Gruß Manfred
Ich danke euch (Tobias, Christian und Manfred) für eure Antworten, ich werde mir insbesondere mal anschauen, auf den Snapshot vor dem Kernelupdate zurückzusetzen. Wäre schön, wenn es funktioniert :-) Gruß Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (5)
-
Christian Meseberg -
Denis Wollenhaupt -
Manfred Kreisl -
Martin Deppe -
Tobias Crefeld