btrfsck kann FS nicht reparieren
Hallo allerseits, anscheiend hat mein btrfs Probleme, denn auf manche Dateien kann ich nicht mehr zugreifen > ls /home/vollmer/projekte/..../FUB22V03 liefert: bash: /home/vollmer/projekte/..../FUB22V03: Veraltete Dateizugriffsnummer (file handle) ein btrfsck --repair liefert btrfs check[0x406fc4] enabling repair mode Checking filesystem on /dev/sda1 UUID: 92d18742-caab-4ce9-b9c9-91a787188cc1 checking extents Check tree block failed, want=902238212, have=4294967296 Check tree block failed, want=902238212, have=4294967296 Check tree block failed, want=902238212, have=4294967296 Check tree block failed, want=902238212, have=4294967296 Check tree block failed, want=902238212, have=4294967296 read block failed check_tree_block extent_io.c:150: insert_state: Assertion `end < start` failed. btrfs check[0x43ca4d] btrfs check[0x43cca2] btrfs check[0x43d0e6] btrfs check[0x434366] btrfs check[0x41d226] btrfs check[0x41dd46] btrfs check[0x406ec2] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7fa763d3cb05] ohne --repair liefert btrfsck rund 152.000 Fehler der Art root 595 inode 66261 errors 2000, link count wrong unresolved ref dir 19976715 index 53 namelen 72 name vorstellung-stiftung-buergersaal-boetzingen-2008-02-13-rede-cornelia.odt filetype 0 errors 3, no dir item, no dir index root 595 inode 66330 errors 2000, link count wrong unresolved ref dir 7522008 index 2 namelen 10 name fonts.conf filetype 0 errors 3, no dir item, no dir index root 595 inode 786293 errors 2000, link count wrong unresolved ref dir 16950101 index 10 namelen 16 name dokuwiki-archive filetype 0 errors 3, no dir item, no dir index root 595 inode 786312 errors 2000, link count wrong unresolved ref dir 16950101 index 5 namelen 3 name etc filetype 0 errors 3, no dir item, no dir index root 595 inode 786314 errors 2000, link count wrong unresolved ref dir 16950101 index 11 namelen 18 name dokuwiki-old-stuff filetype 0 errors 3, no dir item, no dir index root 595 inode 872838 errors 2000, link count wrong Was tun? Wie stelle ich sicher, dass mir da nicht mal der ganze Dateibaum kaputt ist. (Ja ich habe eine Datensicherung, die auch lange zurück reicht) Ich benutze ein aktuell gehaltenes SuSE 13.1 Schönen 4. Advent & Bye Jürgen -- Dr.rer.nat. Jürgen Vollmer, Am Rennbuckel 21, D-76185 Karlsruhe Tel: +49(721) 92 04 87 1 Fax: +49(721) 92 04 87 2 Juergen.Vollmer@informatik-vollmer.de www.informatik-vollmer.de ------------------------------------------------------------------------------- Diese EMail ist elektronisch mittels GPG / PGP signiert. Diese elektronische Unterschrift ist in einem EMail-Anhang enthalten. Leider kann die Signatur ohne die Installation entsprechender Programme weder geprüft noch angezeigt werden. Mehr dazu unter: http://www.gnupg.org oder auch http://www.pgpi.org -------------------------------------------------------------------------------
Am Sonntag, 20. Dezember 2015, 13:15:04 schrieb Dr. Juergen Vollmer:
(...). Was tun? Wie stelle ich sicher, dass mir da nicht mal der ganze Dateibaum kaputt ist. (Ja ich habe eine Datensicherung, die auch lange zurück reicht)
Ich benutze ein aktuell gehaltenes SuSE 13.1
Mit dem Reparieren von btrfs habe ich keine Erfahrung. Grundsätzlich, also unabhängig vom Dateisystemtyp, würde ich eine Reparatur immer mit den aktuellen Tools probieren. Hier btrfsprogs aus openSUSE BuildService - filesystems: http://download.opensuse.org/repositories/filesystems/openSUSE_13.1/ Falls dir die Daten wichtig sind, natürlich erst ein aktuelles Backup bevor du ein repair probierst. Gruß Jan -- No other person has the right to decide what is moral (right or wrong) for you. -- 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
On Sun, 20 Dec 2015 13:15:04 +0100
"Dr. Juergen Vollmer"
Hallo allerseits,
anscheiend hat mein btrfs Probleme, denn auf manche Dateien kann ich nicht mehr zugreifen [...] Was tun?
Kein btrfs verwenden
Wie stelle ich sicher, dass mir da nicht mal der ganze Dateibaum kaputt ist. (Ja ich habe eine Datensicherung, die auch lange zurück reicht)
Deine Daten die _jetzt_ noch zu retten sind auf ein ext4 umkopieren.
Ich benutze ein aktuell gehaltenes SuSE 13.1
Das spielt keine Rolle. btrfs geht in keiner Version so dass man es produktiv verwenden kann. <Meinung> Ich habe in der btrfs Mailingliste schon vor Jahren das Ding mit einem Saurier verglichen. Es frisst alle Manpower-Resourcen auf, wird gross und unuebersichtlich und am Ende wird es aussterben genau weil es gross und unuebersichtlich ist. Es ist wirklich nur ein Demoobjekt fuer die Genialitaet des Autors, aber das haetten ihm viele (inkl. mir) auch ohne diesen Code geglaubt. </Meinung>
Schönen 4. Advent & Bye
Jürgen
Ebenfalls frohe Weihnachten -- MfG, Stephan -- 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 Jürgen, Am 20.12.2015 um 13:15 schrieb Dr. Juergen Vollmer:
Hallo allerseits,
ls /home/vollmer/projekte/..../FUB22V03
anscheiend hat mein btrfs Probleme, denn auf manche Dateien kann ich nicht mehr zugreifen liefert: bash: /home/vollmer/projekte/..../FUB22V03: Veraltete Dateizugriffsnummer (file handle)
ein btrfsck --repair liefert
btrfs check[0x406fc4] enabling repair mode Checking filesystem on /dev/sda1 UUID: 92d18742-caab-4ce9-b9c9-91a787188cc1 checking extents Check tree block failed, want=902238212, have=4294967296 Check tree block failed, want=902238212, have=4294967296 Check tree block failed, want=902238212, have=4294967296 Check tree block failed, want=902238212, have=4294967296 Check tree block failed, want=902238212, have=4294967296 read block failed check_tree_block extent_io.c:150: insert_state: Assertion `end < start` failed. btrfs check[0x43ca4d] btrfs check[0x43cca2] btrfs check[0x43d0e6] btrfs check[0x434366] btrfs check[0x41d226] btrfs check[0x41dd46] btrfs check[0x406ec2] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7fa763d3cb05]
ohne --repair liefert btrfsck rund 152.000 Fehler der Art root 595 inode 66261 errors 2000, link count wrong unresolved ref dir 19976715 index 53 namelen 72 name vorstellung-stiftung-buergersaal-boetzingen-2008-02-13-rede-cornelia.odt filetype 0 errors 3, no dir item, no dir index root 595 inode 66330 errors 2000, link count wrong unresolved ref dir 7522008 index 2 namelen 10 name fonts.conf filetype 0 errors 3, no dir item, no dir index root 595 inode 786293 errors 2000, link count wrong unresolved ref dir 16950101 index 10 namelen 16 name dokuwiki-archive filetype 0 errors 3, no dir item, no dir index root 595 inode 786312 errors 2000, link count wrong unresolved ref dir 16950101 index 5 namelen 3 name etc filetype 0 errors 3, no dir item, no dir index root 595 inode 786314 errors 2000, link count wrong unresolved ref dir 16950101 index 11 namelen 18 name dokuwiki-old-stuff filetype 0 errors 3, no dir item, no dir index root 595 inode 872838 errors 2000, link count wrong
Was tun? Wie stelle ich sicher, dass mir da nicht mal der ganze Dateibaum kaputt ist. (Ja ich habe eine Datensicherung, die auch lange zurück reicht)
Ich benutze ein aktuell gehaltenes SuSE 13.1 Habe ich auch.
Ich kann Dir nur ans Herz legen, sich die neuesten btrfsprogs zu installieren, die bei der 13.1 dabei sind taugen nichts (total veraltet). Mit den 'orginalen' war ich auch nie in der Lage, ein FS zu reparieren, Coredumps waren an der Tagesordnung. Nun, da ich kürzlich meine root Partition auf eine SSD verschieben musste (durfte :-)), war in diesem Zusammenhang auch ein Check mit --repair vonnöten, da sonst gparted immer herumnörgelte. Mit den btrfsprogs-4.3.1-213.1.x86_64 hat es dann anstandslos funktioniert. Damit kann man übrigens auch die UUID ändern lg und ebenfalls schönen 4. Advent 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
Hallo Manfred, Am Sonntag, 20. Dezember 2015, 20:21:12 schrieb Manfred Kreisl:
Hallo Jürgen,
Am 20.12.2015 um 13:15 schrieb Dr. Juergen Vollmer:
Hallo allerseits,
ls /home/vollmer/projekte/..../FUB22V03
anscheiend hat mein btrfs Probleme, denn auf manche Dateien kann ich nicht mehr zugreifen liefert: bash: /home/vollmer/projekte/..../FUB22V03: Veraltete Dateizugriffsnummer (file handle)
....
Was tun? Wie stelle ich sicher, dass mir da nicht mal der ganze Dateibaum kaputt ist. (Ja ich habe eine Datensicherung, die auch lange zurück reicht)
Ich benutze ein aktuell gehaltenes SuSE 13.1 Habe ich auch.
Ich kann Dir nur ans Herz legen, sich die neuesten btrfsprogs zu installieren, die bei der 13.1 dabei sind taugen nichts (total veraltet). Mit den 'orginalen' war ich auch nie in der Lage, ein FS zu reparieren, Coredumps waren an der Tagesordnung. Nun, da ich kürzlich meine root Partition auf eine SSD verschieben musste (durfte :-)), war in diesem Zusammenhang auch ein Check mit --repair vonnöten, da sonst gparted immer herumnörgelte. Mit den btrfsprogs-4.3.1-213.1.x86_64 hat es dann anstandslos funktioniert. Damit kann man übrigens auch die UUID ändern
lg und ebenfalls schönen 4. Advent
Manfred
hab' die aktuellen btrfs-Tools instralliert. btrfsck meldet nun keine Fehler mehr und --repair hat nichts mehr zu reparieren ich habe nun ein Verzeichnis identifiziert, welches Probleme machte. Es enthielt rund 54.000 sym-links; nachdem die die meisten gelöscht habe und mir den Inhalt des Verzeichnisses anzeigen lasse, dann erscheint bei ls -l ls: Zugriff auf FUB22V03 nicht möglich: Veraltete Dateizugriffsnummer (file handle) ls: Zugriff auf FUB22V04 nicht möglich: Veraltete Dateizugriffsnummer (file handle) ls: Zugriff auf FUB22V05 nicht möglich: Veraltete Dateizugriffsnummer (file handle) ls: Zugriff auf FUB22V07 nicht möglich: Veraltete Dateizugriffsnummer (file handle) ls: Zugriff auf FUB22V08 nicht möglich: Veraltete Dateizugriffsnummer (file handle) ls: Zugriff auf FUB22V09 nicht möglich: Veraltete Dateizugriffsnummer (file handle) ls: Zugriff auf FUB22V11 nicht möglich: Veraltete Dateizugriffsnummer (file handle) ls: Zugriff auf FUB22V12 nicht möglich: Veraltete Dateizugriffsnummer (file handle) ls: Zugriff auf FUB230 nicht möglich: Veraltete Dateizugriffsnummer (file handle) ls: Zugriff auf FUB23V01 nicht möglich: Veraltete Dateizugriffsnummer (file handle) ls: Zugriff auf FUB23V02 nicht möglich: Veraltete Dateizugriffsnummer (file handle) insgesamt 0 l????????? ? ? ? ? ? FUB22V03 l????????? ? ? ? ? ? FUB22V04 l????????? ? ? ? ? ? FUB22V05 l????????? ? ? ? ? ? FUB22V07 l????????? ? ? ? ? ? FUB22V08 l????????? ? ? ? ? ? FUB22V09 l????????? ? ? ? ? ? FUB22V11 l????????? ? ? ? ? ? FUB22V12 l????????? ? ? ? ? ? FUB230 l????????? ? ? ? ? ? FUB23V01 l????????? ? ? ? ? ? FUB23V02 also ist immer noch was kaputt, nur wie bekomme ich das nun gefixed? Bye Jürgen -- Dr.rer.nat. Jürgen Vollmer, Am Rennbuckel 21, D-76185 Karlsruhe Tel: +49(721) 92 04 87 1 Fax: +49(721) 92 04 87 2 Juergen.Vollmer@informatik-vollmer.de www.informatik-vollmer.de ------------------------------------------------------------------------------- Diese EMail ist elektronisch mittels GPG / PGP signiert. Diese elektronische Unterschrift ist in einem EMail-Anhang enthalten. Leider kann die Signatur ohne die Installation entsprechender Programme weder geprüft noch angezeigt werden. Mehr dazu unter: http://www.gnupg.org oder auch http://www.pgpi.org ------------------------------------------------------------------------------- -- 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 Jürgen, Am 22.12.2015 um 09:18 schrieb Dr. Juergen Vollmer: [...]
hab' die aktuellen btrfs-Tools instralliert. btrfsck meldet nun keine Fehler mehr und --repair hat nichts mehr zu reparieren
ich habe nun ein Verzeichnis identifiziert, welches Probleme machte. Es enthielt rund 54.000 sym-links; nachdem die die meisten gelöscht habe und mir den Inhalt des Verzeichnisses anzeigen lasse, dann erscheint bei
ls -l
ls: Zugriff auf FUB22V03 nicht möglich: Veraltete Dateizugriffsnummer (file handle) ls: Zugriff auf FUB22V04 nicht möglich: Veraltete Dateizugriffsnummer (file handle) ls: Zugriff auf FUB22V05 nicht möglich: Veraltete Dateizugriffsnummer (file handle) ls: Zugriff auf FUB22V07 nicht möglich: Veraltete Dateizugriffsnummer (file handle) ls: Zugriff auf FUB22V08 nicht möglich: Veraltete Dateizugriffsnummer (file handle) ls: Zugriff auf FUB22V09 nicht möglich: Veraltete Dateizugriffsnummer (file handle) ls: Zugriff auf FUB22V11 nicht möglich: Veraltete Dateizugriffsnummer (file handle) ls: Zugriff auf FUB22V12 nicht möglich: Veraltete Dateizugriffsnummer (file handle) ls: Zugriff auf FUB230 nicht möglich: Veraltete Dateizugriffsnummer (file handle) ls: Zugriff auf FUB23V01 nicht möglich: Veraltete Dateizugriffsnummer (file handle) ls: Zugriff auf FUB23V02 nicht möglich: Veraltete Dateizugriffsnummer (file handle) insgesamt 0 l????????? ? ? ? ? ? FUB22V03 l????????? ? ? ? ? ? FUB22V04 l????????? ? ? ? ? ? FUB22V05 l????????? ? ? ? ? ? FUB22V07 l????????? ? ? ? ? ? FUB22V08 l????????? ? ? ? ? ? FUB22V09 l????????? ? ? ? ? ? FUB22V11 l????????? ? ? ? ? ? FUB22V12 l????????? ? ? ? ? ? FUB230 l????????? ? ? ? ? ? FUB23V01 l????????? ? ? ? ? ? FUB23V02
also ist immer noch was kaputt, nur wie bekomme ich das nun gefixed?
Das sieht ja nicht gut aus. Leider weiß ich da keinen wirklichen Rat. Es scheint mir dass btrfsck immer noch längst nicht ausgereift ist. Hast Du denn noch Snapshots bei denen das Verzeichnis korrekt ist? Bei mir hat es mal bei einem Rechner das BTRFS zerschossen (war aber nicht die Schuld von BTRFS, sondern hatte da noch die CPU undervolted, was offensichtlich vom BTRFS übel genommen wurde), da war das Root - BTRFS völlig kaputt, die Snapshots aber glücklicherweise alle in Ordnung. Jedenfalls so etwas in der Art kenne ich - nicht von openSUSE, sondern von meinen Raspberry & Co Installationen, die allesamt BTRFS verwenden - da hab ich die Dateisystemfehler dieser Art aber immer weg bekommen. 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
Hallo Manfred, Am Dienstag, 22. Dezember 2015, 16:05:28 schrieb Manfred Kreisl:
l????????? ? ? ? ? ? FUB230 l????????? ? ? ? ? ? FUB23V01 l????????? ? ? ? ? ? FUB23V02
also ist immer noch was kaputt, nur wie bekomme ich das nun gefixed? Das sieht ja nicht gut aus. Leider weiß ich da keinen wirklichen Rat.
Es scheint mir dass btrfsck immer noch längst nicht ausgereift ist.
Hast Du denn noch Snapshots bei denen das Verzeichnis korrekt ist? Bei mir hat es mal bei einem Rechner das BTRFS zerschossen (war aber nicht die Schuld von BTRFS, sondern hatte da noch die CPU undervolted, was offensichtlich vom BTRFS übel genommen wurde), da war das Root - BTRFS völlig kaputt, die Snapshots aber glücklicherweise alle in Ordnung.
Jedenfalls so etwas in der Art kenne ich - nicht von openSUSE, sondern von meinen Raspberry & Co Installationen, die allesamt BTRFS verwenden - da hab ich die Dateisystemfehler dieser Art aber immer weg bekommen.
es scheint auch bei mir ein Problem mit der CPU (Hitze, neuer Kühler ist nun drauf) gegeben zu haben, da haben sich die CPU einfach abgeschalten.... Kann echt sein, dass da btrfs pienzig ist, wenn das gerade in einem kritischen Moment passiert. Aber das ist nur Glaskugel gucken.... Was mir aber nun auffällt ist, dass wenn ich eine Datensicherung mit rsanpshot/rsync auf eine separate Platte mache, dass die CPUs plötzlich auf 100% Last fahren, und dann der Rechner steht. Der Stacktrace in ehemals /var/log/messages zeigt, dass die CPU gerade mit btrfs beschäftigt war. .... Ein Snapshot habe ich nicht , sondern nur Datensicherungen. Aber glücklicherweise sind das keine kritischen Daten. ich werd' jetzt nochmals eine Kopie ohne das kritische Verzeichnis erstellen, dann /home neu formatieren (mit btrfs :-) und dann ohne die kritischen Sachen zurückspielen. /in der Hoffnung, dass nur dieses Verzeichnis das Problem hat) Irgendwelche Tips dazu OK, /home habe ich im Laufe der Zeit schon öfters so umgezogen: defekte Platten, defekte oder neue PC's, Probleme mit diversen FS, .... (Ist immer eine spannende Sache, wenn da echte Produktivdaten drauf sind, die echtes Geld wert sind :-) Bye Jürgen -- 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 20.12.2015 um 13:15 schrieb Dr. Juergen Vollmer:
Hallo allerseits,
anscheiend hat mein btrfs Probleme, denn auf manche Dateien kann ich nicht mehr zugreifen
Ich kann zwar nicht helfen, danke dir aber trotzdem, dass du dein Problem mit der Community teilst! Denn dadurch hast du die Richtigkeit meiner Entscheidung bekräftigt, nur noch auf XFS zu setzen :-) XFS ist stabil und flott, m.E. btrfs ist *vielleicht* mal ne Option in 2 oder 3 Jahren. Gruß Malte -- 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
Hi Malte, Am Montag, 21. Dezember 2015, 02:02:43 schrieb Malte Gell:
Am 20.12.2015 um 13:15 schrieb Dr. Juergen Vollmer:
Hallo allerseits,
anscheiend hat mein btrfs Probleme, denn auf manche Dateien kann ich nicht mehr zugreifen
Ich kann zwar nicht helfen, danke dir aber trotzdem, dass du dein Problem mit der Community teilst!
Denn dadurch hast du die Richtigkeit meiner Entscheidung bekräftigt, nur noch auf XFS zu setzen :-) XFS ist stabil und flott, m.E.
btrfs ist *vielleicht* mal ne Option in 2 oder 3 Jahren.
ach, ich hatte jahrelang ext2 und dann ext3 im Einsatz, bis die Prozessoren so schnell wurden, dass beim Nachübersetzen von Software mittels make die Datei-Zeitstempel nicht präzise genug waren, so dass die Nachübersetzung nicht mehr funktioniert, hat lange gedauert das Phänomen zu verstehen. Dann jahrelang XFS (hatte millisekunden Zeitstempel) auch das war buggy, auch hier Dateien verloren und "bitrotten". (Gottseidank waren nur generierte Dateien betroffen, und andre waren im Backup noch da) dann LVM + EXT4, aber bei mehreren 10.000 Dateien pro Verzeichnis (COBOL-Quellen vom IBM-Mainframe waren die Testquellen für meine Tools, Mainframes haben keine Probleme mit vielen Dateien pro "Verzeichnis"). Ein simples ls in so einem ext4 Verzeichnis dauert..... dann btrfs, hatte LVM "eingebaut", und konnte auch mit vielen Dateien in einem Verzeichnis umgehen. Nun eben auch wieder bugs. So what. Dateisystem sind keine Glaubenssache, sondern müssen Anforderungen erfüllen. Software ist eben buggy, .... man muss das beste d'raus machen, und Vorsorge treffen.... Hab' jetzt mal die neuen btrfs-Tools installiert, doppeltes backup gemacht und werde dann man btrfsck --repair aufrufen, und ggf. eben das FS neu aufsetzen.... Bye Jürgen -- Dr.rer.nat. Jürgen Vollmer, Am Rennbuckel 21, D-76185 Karlsruhe Tel: +49(721) 92 04 87 1 Fax: +49(721) 92 04 87 2 Juergen.Vollmer@informatik-vollmer.de www.informatik-vollmer.de ------------------------------------------------------------------------------- Diese EMail ist elektronisch mittels GPG / PGP signiert. Diese elektronische Unterschrift ist in einem EMail-Anhang enthalten. Leider kann die Signatur ohne die Installation entsprechender Programme weder geprüft noch angezeigt werden. Mehr dazu unter: http://www.gnupg.org oder auch http://www.pgpi.org -------------------------------------------------------------------------------
participants (5)
-
Dr. Juergen Vollmer -
Jan Ritzerfeld -
Malte Gell -
Manfred Kreisl -
Stephan von Krawczynski