Tumbleweed: BTRFS Defrag defekt?
Hallo! Ist auf Tumbleweed (x64) das BTRFS Defrag kaputt? Ich habe hier auf verschiedenen Tumbleweed mit verschiedenen Festplatten und Filesystemen dasselbe Phänomen: Ein btrfs filesystem defragment -rv /path/ läuft eine kleine Weile und bleibt dann mit 100% auf einem CPU-Kern stehen. Der wechselt dann über die verschiedenen Kerne, aber es geht nicht mehr weiter. Die FS sind OK, verschiedene, getestet mit btrfs check, neu angelegt und neu mit Daten bespielt. Jmd. 'ne Idee was da hakt, bzw. kann den Maintendern mal Bescheid geben? Tschö' Sue
On 19.01.22 15:07, Sandre Useres wrote:
Ist auf Tumbleweed (x64) das BTRFS Defrag kaputt?
Ich habe hier auf verschiedenen Tumbleweed mit verschiedenen Festplatten und Filesystemen dasselbe Phänomen: Ein
btrfs filesystem defragment -rv /path/
läuft eine kleine Weile und bleibt dann mit 100% auf einem CPU-Kern stehen. Der wechselt dann über die verschiedenen Kerne, aber es geht nicht mehr weiter.
Ggf. https://lore.kernel.org/linux-btrfs/2d4ed9ca-52a7-3a39-1a4f-995c6ed0d070@gmx... ? Zumindest hier kann ich das mit 1 Byte großen Dateien reproduzieren.
Jmd. 'ne Idee was da hakt, bzw. kann den Maintendern mal Bescheid geben?
Der übliche Weg, dass den Maintainern mitzuteilen, wäre ein Bugreport. Viele Grüße Ulf
Am 19.01.22 um 15:07 schrieb Sandre Useres:
Ist auf Tumbleweed (x64) das BTRFS Defrag kaputt?
Ich habe hier auf verschiedenen Tumbleweed mit verschiedenen Festplatten und Filesystemen dasselbe Phänomen: Ein
btrfs filesystem defragment -rv /path/
läuft eine kleine Weile und bleibt dann mit 100% auf einem CPU-Kern stehen. Der wechselt dann über die verschiedenen Kerne, aber es geht nicht mehr weiter.
Mit Kernel 5.16.5 scheint der Fehler behoben... Tschö' Sue
Am 19.01.22 um 15:07 schrieb Sandre Useres:
Ist auf Tumbleweed (x64) das BTRFS Defrag kaputt?
Ich habe hier auf verschiedenen Tumbleweed mit verschiedenen Festplatten und Filesystemen dasselbe Phänomen: Ein
btrfs filesystem defragment -rv /path/
läuft eine kleine Weile und bleibt dann mit 100% auf einem CPU-Kern stehen. Der wechselt dann über die verschiedenen Kerne, aber es geht nicht mehr weiter.
Mit Kernel 5.16.5 scheint der Fehler behoben...
Oder auch nicht... Hier lösen sich grad GBs an Platz in Luft auf. :-( Also entweder ist hier das FS kaputt, oder Defrag schreibt munter Daten ohne den alten Platz freizugeben. :-/ Solltet Ihr testen bevor es wehtut... Tschö' Sue
Am 12.02.22 um 19:47 schrieb suse:
Ist auf Tumbleweed (x64) das BTRFS Defrag kaputt? ...
Mit Kernel 5.16.5 scheint der Fehler behoben...
Oder auch nicht... Hier lösen sich grad GBs an Platz in Luft auf. :-(
Also entweder ist hier das FS kaputt, oder Defrag schreibt munter Daten ohne den alten Platz freizugeben. :-/
Kurios, auf Leap mit Kernel 5.3.18-lp152.106-default, gibt ein Defrag den falsch belegten Speicher nach und nach wieder frei. Wenn Ihr also BTRFS Systeme mit Tumbleweed habt, solltet ihr zur Zeit auf Defrag besser verzichten. Werde berichten, wenn sich das wieder ändert... Tschö' Sue
Am 12.02.22 um 19:47 schrieb suse:
Ist auf Tumbleweed (x64) das BTRFS Defrag kaputt? Ich habe hier auf verschiedenen Tumbleweed mit verschiedenen Festplatten und Filesystemen dasselbe Phänomen: Ein
btrfs filesystem defragment -rv /path/
läuft eine kleine Weile und bleibt dann mit 100% auf einem CPU-Kern stehen. Der wechselt dann über die verschiedenen Kerne, aber es geht nicht mehr weiter.
Mit Kernel 5.16.5 scheint der Fehler behoben...
Oder auch nicht... Hier lösen sich grad GBs an Platz in Luft auf. :-(
Also entweder ist hier das FS kaputt, oder Defrag schreibt munter Daten ohne den alten Platz freizugeben. :-/
Mittlerweile Kernel 5.17.1 und btrfs defrag frisst immer noch Plattenplatz. :-( Nach etlichen Versuchen (Scrub, Balance, Speicher freigeben, etc.) scheint die einzige Lösung die FS neu anzulegen. Und das ist eine ziemlich doofe Lösung, da das wieder bespielen mit den Daten bei einer 10T-Platten rund anderthalb Tage braucht. Da bin ich die nächsten Wochen mit nix anderem beschäftigt, da es hier viele Platten hat. :-/ Es scheinen auch nicht alle Platten betroffen, obwohl alle aus einem Pulk jeweils gleich erzeugt/aufgesetzt wurden, und die Platten im Backupsystem ideln, also auch in Ruhe mit neuen Daten beschrieben werden. Insgesamt eine völlig unbefriedigende Situation, die mich gerade sehr am Produktiveinsatz von BTRFS zweifeln läßt. Kann doch nicht sein funktionierende FS neu machen zu müssen, blos weil sich irgendwo was geändert hat? Und wie machen das andere Betroffene mit richtig vielen Daten? Habe versucht jmd. vom BTRFS-Team zu erreichen, leider ohne Erfolg. Falls Ihr einen Kontakt herstellen könnt, bitte PM, danke. Tschö' Sue
participants (3)
-
Sandre Useres -
suse
-
Ulf Volmer