Hallo, mein Root FS ist BTRFS (opensuse 12.1). Nun habe ich einige Dateien gefunden, bei denen ls folgendes anzeigt: # ls -l /usr/share/man/man3p/wait* ls: cannot access /usr/share/man/man3p/wait.3p.gz: Stale NFS file handle ls: cannot access /usr/share/man/man3p/waitid.3p.gz: Stale NFS file handle ls: cannot access /usr/share/man/man3p/waitpid.3p.gz: Stale NFS file handle Die Files sind in allen Snapshots außer dem ersten kaputt. Dort sieht das so aus: # ls -l /.snapshots/1/snapshot/usr/share/man/man3p/wait* -rw-r--r-- 1 root root 6161 Jun 5 2008 /.snapshots/1/snapshot/usr/share/man/man3p/wait.3p.gz -rw-r--r-- 1 root root 1808 Jun 5 2008 /.snapshots/1/snapshot/usr/share/man/man3p/waitid.3p.gz -rw-r--r-- 1 root root 38 Jun 5 2008 /.snapshots/1/snapshot/usr/share/man/man3p/waitpid.3p.gz Löschen oder Umbenennen lassen sich solche Dateien auch nicht. Aufgrund der Manpage von btrfsck: btrfsck is part of btrfs-progs. Btrfs is currently under heavy development, and not suitable for any uses other than benchmarking and review. nehme ich an, dass es keinen Sinn hat, damit zu versuchen, das FS zu reparieren. Naja, bis in den September wird es schon noch funktionieren. Dann gibt es 12.2 und das Root FS wird wieder ext4. Es war halt ein Experiment. Torsten -- 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 Sat, Aug 04, 2012 at 12:41:18PM +0200, Torsten Förtsch wrote:
mein Root FS ist BTRFS (opensuse 12.1). Nun habe ich einige Dateien gefunden, bei denen ls folgendes anzeigt:
# ls -l /usr/share/man/man3p/wait* ls: cannot access /usr/share/man/man3p/wait.3p.gz: Stale NFS file handle ls: cannot access /usr/share/man/man3p/waitid.3p.gz: Stale NFS file handle ls: cannot access /usr/share/man/man3p/waitpid.3p.gz: Stale NFS file handle
... und die Fehlermeldung besagt daß die Dateien von einem NFS-Server(!) nicht mehr bereit stehen. Hat also mit BTRFS nichts zu tun. Hast du ein NFS-Verzeichnis gemountet? Falls du dir unsicher bist sende die Ausgabe von $ mount [...]
Löschen oder Umbenennen lassen sich solche Dateien auch nicht.
Siehe oben: er Meldung nach kommen diese Dateien (oder das Verzeichnis dieser Dateien) von einem NFS-Server und wurden *dort* zwischenzeitlich gelöscht/umbenannt/whatever sprich die sind nicht mehr verfügbar. Ein paar mögliche Lösungen hier http://sysunconfig.net/unixtips/stale_nfs.txt flo -- 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 08/04/2012 09:45 PM, Florian Groß wrote:
On Sat, Aug 04, 2012 at 12:41:18PM +0200, Torsten Förtsch wrote:
mein Root FS ist BTRFS (opensuse 12.1). Nun habe ich einige Dateien gefunden, bei denen ls folgendes anzeigt:
# ls -l /usr/share/man/man3p/wait* ls: cannot access /usr/share/man/man3p/wait.3p.gz: Stale NFS file handle ls: cannot access /usr/share/man/man3p/waitid.3p.gz: Stale NFS file handle ls: cannot access /usr/share/man/man3p/waitpid.3p.gz: Stale NFS file handle ... und die Fehlermeldung besagt daß die Dateien von einem NFS-Server(!) nicht mehr bereit stehen. Hat also mit BTRFS nichts zu tun.
Hast du ein NFS-Verzeichnis gemountet? Falls du dir unsicher bist sende die Ausgabe von $ mount
Meinst Du, ich hätte diese Mail geschrieben, wenn das auf einem per NFS gemounteten FS aufgetreten wäre? Die Dateien liegen im Root FS und das ist BTRFS (or perhaps WRSFS). Und da macht die Fehlermeldung keinen Sinn. Gut, die Kiste ist seit der Installation von 12.1 einige Male so hängen geblieben, dass nur noch der I/O Knopf half. Aber Ext4 hätte das erkannt und mit großer Wahrscheinlichkeit repariert. Ich hatte BTRFS als Experiment installiert, weil ich die Snapshots interessant fand. Leider muss ich sagen, das es ein Fehlschlag war: - inkonsistente Aussagen von df und du. Hier würde ich mir ein df per Snapshot wünschen. Außerdem habe ich den Eindruck, dass bei BTRFS einiges an Plattenplatz einfach so verloren geht: # du -shx / du: cannot access `/usr/share/man/man3p/unsetenv.3p.gz': Stale NFS file handle du: cannot access `/usr/share/man/man3p/usleep.3p.gz': Stale NFS file handle du: cannot access `/usr/share/man/man3p/wait.3p.gz': Stale NFS file handle du: cannot access `/usr/share/man/man3p/waitid.3p.gz': Stale NFS file handle du: cannot access `/usr/share/man/man3p/waitpid.3p.gz': Stale NFS file handle 6.1G / # df -h / Filesystem Size Used Avail Use% Mounted on /dev/mapper/system-root 40G 24G 8.2G 75% / Gut, ich habe 145 von Snapper (Standardkonfiguration) angelegte Snapshots. Aber ich kann mir nicht vorstellen, dass diese Copy-on-write Snapshots das 3-fache der eigentlichen Daten belegen. - "zypper ps" ist mit BTRFS sinnlos, da zypper jedes mal einen neuen Snapshot anlegt und sich dadurch die Device Nummer ändert. # stat -c '%D %n' /.snapshots/2505/snapshot/etc/motd /etc/motd b3 /.snapshots/2505/snapshot/etc/motd 14 /etc/motd "zypper ps" denkt dann, dass alle gerade benutzten Dateien von einem anderen Filesystem stammen. So kommt es zu dem Schluss, dass ein Reboot unbedingt nötig ist, um die neuen Versionen zu laden. - Und nun noch das "Stale NFS file". Das nächste Mal wird es daher wieder Ext4. Übrigens habe ich einige Hinweise aus dem letzten Jahr auf Snapshots (nicht LVM-basiert) in Ext4 gefunden. Weiß jemand, ob der mit 12.2 kommende Kernel diese unterstützt? Kann Snapper damit umgehen? Torsten -- 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, 05 Aug 2012 15:08:22 +0200, Torsten Förtsch <torsten.foertsch@gmx.net> wrote:
- inkonsistente Aussagen von df und du. Hier würde ich mir ein df per Snapshot wünschen.
Das musst Du dann, wenn überhaupt, den Coreutils-Entwicklern ankreiden, denn die sind für df und du zuständig.
- "zypper ps" ist mit BTRFS sinnlos, da zypper jedes mal einen neuen Snapshot anlegt und sich dadurch die Device Nummer ändert.
Das ist aber vor allem ein Problem von zypper, nicht von btrfs. Philipp -- 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 05.08.2012 15:08, schrieb Torsten Förtsch:
# du -shx / ... 6.1G /
# df -h / Filesystem Size Used Avail Use% Mounted on /dev/mapper/system-root 40G 24G 8.2G 75% /
Unabhängig von btrfs hatte ich diese Diskrepanz auch schon unter ext4. Die Ursache lag in einer geöffneten Datei, welche gelöscht wurde und danach weiter mit log Meldungen voll gespammt wurde (~/xsession-errors). du zeigte für /home eine Befüllung von ca 36 G. Nach df war /home mit 50G zu 100% gefüllt. Google bringt einige Treffer zu diesem unterschiedlichen Verhalten. War da nicht auch mal was hier auf der Liste? Grüße Ralf -- Antworten bitte nur in die Mailingliste! PMs bitte an: listpm (@) arndt-de (.) eu -- 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 08/04/2012 12:41 PM, Torsten Förtsch wrote:
# ls -l /usr/share/man/man3p/wait* ls: cannot access /usr/share/man/man3p/wait.3p.gz: Stale NFS file handle ls: cannot access /usr/share/man/man3p/waitid.3p.gz: Stale NFS file handle ls: cannot access /usr/share/man/man3p/waitpid.3p.gz: Stale NFS file handle
Die Files sind in allen Snapshots außer dem ersten kaputt. Dort sieht das so aus:
# ls -l /.snapshots/1/snapshot/usr/share/man/man3p/wait* -rw-r--r-- 1 root root 6161 Jun 5 2008 /.snapshots/1/snapshot/usr/share/man/man3p/wait.3p.gz -rw-r--r-- 1 root root 1808 Jun 5 2008 /.snapshots/1/snapshot/usr/share/man/man3p/waitid.3p.gz -rw-r--r-- 1 root root 38 Jun 5 2008 /.snapshots/1/snapshot/usr/share/man/man3p/waitpid.3p.gz
Löschen oder Umbenennen lassen sich solche Dateien auch nicht.
Nachtrag: Eigentlich wollte ich mit der Neuinstallation ohne BTRFS auf 12.2 warten. Das ist jetzt nicht mehr nötig. Gestern wollte ich ein wenig Platz schaffen und habe die snapper Konfiguration etwas angepasst. Direkt nach dem "snapper cleanup" war noch alles gut und regelmäßige df Aufrufe zeigten, dass der freie Platz auf der Platte wuchs. Irgendwann veranlasste mich irgendwas, per tail /var/log/messages betrachten zu wollen. Da sich eine Weile nichts tat, schaute ich den Prozess mit ps an. Als Status wurde D angezeigt. Er wartete also auf irgendein Gerät, offensichtlich die Platte. Viele andere Programme verhielten sich dann genauso - ein recht sicheres Zeichen für ein ganz kaputtes Filesystem. Es stand also eine Neuinstallation an. Nach dem Booten von der DVD wählte ich Neuinstallation aus. Doch recht früh, noch bevor das Installationsprogramm irgendwas auf die Platte schreibt, analysiert es das System und sucht nach Linux Partitionen. Dabei versucht es offensichtlich diese auch zu mounten, was in meinem Fall nun mit einer endlosen Folge von Kernel-Fehlern (Stack Traces, die irgendwas mit btrfs zu tun hatten) endete. Das Rescue System bootete dann zum Glück, ohne sich die Platte angucken zu wollen. Die LVM Tools zum Aktivieren der Partitionen und mkfs waren auch vorhanden. So fand ich meine ehemalige Root-Partition und schrieb kurzerhand ein ext4 drauf. Danach funktionierte auch die Neuinstallation. Fazit: BTRFS ist in meinen Augen definitiv noch nicht fertig und schon gar nicht für Otto-Normalverbraucher geeignet, denn es kann dazu führen, dass selbst eine Neuinstallation von DVD zunächst scheitert. Torsten -- 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 (4)
-
Florian Groß -
Philipp Thomas -
Ralf Arndt -
Torsten Förtsch