10 Apr
2020
10 Apr
'20
3:46 a.m.
Hi,
in der letzten Woche gab es Updates u. a. im Bereich btrfs. In etwa seit
diesem Zeitpunkt bemerkte ich zwei Auffälligkeiten:
- Das Abschalten ist nicht erfolgreich.
Die GUI et.al. wird beendet, aber der Rechner bleibt irgendwie 'an'. Die
Hintergrundbeleuchtung des Monitors geht nicht aus und die LED die den
Zugriff auf die HDD (hier SSD) anzeigen soll, leuchtet dauern.
Bisher schalte ich dann nach einigen Minuten immer per Knopf ab.
- TOP zeigt dauernd eine CPU-Last grösser als 1 an.
Außerdem sind die wa immer über 1 (4-Core CPU). Auch zeigt iotop das
btrfs-balance dauernd storage-io verursacht. Dieser Prozess
(btrfs-balance steht im TOP aber auf State 'D'.
- journalctl zeigt viele Meldungen der Art:
BTRFS info (device dm-1) found 1 extends
(dm-1 scheint die root-partition zu sein.)
Ich würde gerne wissen was da los ist, hilfreiche Erläuterungen und
Tipps wo ich etwas finden könnte sind gerne gesehen.
Frohe Ostern
Bernd
--
"Mit Höflichkeit und einer Waffe erreicht
man mehr als nur mit Höflichkeit"
(Putin)
--
Um die Liste abzubestellen, schicken Sie eine Mail an:
opensuse-de+unsubscribe(a)opensuse.org
Um den Listen Administrator zu erreichen, schicken
Sie eine Mail an: opensuse-de+owner(a)opensuse.org
10 Apr
10 Apr
6:29 a.m.
Am Fri, 10 Apr 2020 10:46:46 +0200
schrieb Bernd Nachtigall <bnacht(a)web.de>de>:
Hi,
in der letzten Woche gab es Updates u. a. im Bereich btrfs. In etwa
seit diesem Zeitpunkt bemerkte ich zwei Auffälligkeiten:
- Das Abschalten ist nicht erfolgreich.
Die GUI et.al. wird beendet, aber der Rechner bleibt irgendwie 'an'.
Die Hintergrundbeleuchtung des Monitors geht nicht aus und die LED
die den Zugriff auf die HDD (hier SSD) anzeigen soll, leuchtet dauern.
Bisher schalte ich dann nach einigen Minuten immer per Knopf ab.
- TOP zeigt dauernd eine CPU-Last grösser als 1 an.
Außerdem sind die wa immer über 1 (4-Core CPU). Auch zeigt iotop das
btrfs-balance dauernd storage-io verursacht. Dieser Prozess
(btrfs-balance steht im TOP aber auf State 'D'.
- journalctl zeigt viele Meldungen der Art:
BTRFS info (device dm-1) found 1 extends
(dm-1 scheint die root-partition zu sein.)
Ich würde gerne wissen was da los ist, hilfreiche Erläuterungen und
Tipps wo ich etwas finden könnte sind gerne gesehen.
Das sind vermutlich einerseits systemd Prozesse, die auf Beendigung des
Vorgänger-Prozesses warten, andererseits Indizierungen von BtrFS, denn
das sind ja copy on write Prozesse, für die ein Index erstellt oder
bereinigt werden muss. Hier ein paar Informationen dazu:
https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Copy_on_Write_.28CoW.…
-Dieter
-
--
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E
--
Um die Liste abzubestellen, schicken Sie eine Mail an:
opensuse-de+unsubscribe(a)opensuse.org
Um den Listen Administrator zu erreichen, schicken
Sie eine Mail an: opensuse-de+owner(a)opensuse.org
7:05 a.m.
Am 10.04.20 um 13:29 schrieb Dieter Klünter:
Am Fri, 10 Apr 2020 10:46:46 +0200
schrieb Bernd Nachtigall <bnacht(a)web.de>de>:
Na ja, aber über 4 Stunden lang ... kann das sein?
Bernd
--
Um die Liste abzubestellen, schicken Sie eine Mail an:
opensuse-de+unsubscribe(a)opensuse.org
Um den Listen Administrator zu erreichen, schicken
Sie eine Mail an: opensuse-de+owner(a)opensuse.org
Hi,
in der letzten Woche gab es Updates u. a. im Bereich btrfs. In etwa
seit diesem Zeitpunkt bemerkte ich zwei Auffälligkeiten:
- Das Abschalten ist nicht erfolgreich.
Die GUI et.al. wird beendet, aber der Rechner bleibt irgendwie 'an'.
Die Hintergrundbeleuchtung des Monitors geht nicht aus und die LED
die den Zugriff auf die HDD (hier SSD) anzeigen soll, leuchtet dauern.
Bisher schalte ich dann nach einigen Minuten immer per Knopf ab.
- TOP zeigt dauernd eine CPU-Last grösser als 1 an.
Außerdem sind die wa immer über 1 (4-Core CPU). Auch zeigt iotop das
btrfs-balance dauernd storage-io verursacht. Dieser Prozess
(btrfs-balance steht im TOP aber auf State 'D'.
- journalctl zeigt viele Meldungen der Art:
BTRFS info (device dm-1) found 1 extends
(dm-1 scheint die root-partition zu sein.)
Ich würde gerne wissen was da los ist, hilfreiche Erläuterungen und
Tipps wo ich etwas finden könnte sind gerne gesehen.
Das sind vermutlich einerseits systemd Prozesse, die auf Beendigung des
Vorgänger-Prozesses warten, andererseits Indizierungen von BtrFS, denn
das sind ja copy on write Prozesse, für die ein Index erstellt oder
bereinigt werden muss. Hier ein paar Informationen dazu:
https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Copy_on_Write_.28CoW.…
14 Apr
14 Apr
4:53 a.m.
Am 10.04.20 um 14:05 schrieb Bernd Nachtigall:
Am 10.04.20 um 13:29 schrieb Dieter Klünter:
Was will mir denn diese Anzeige sagen?
# btrfs balance status -v /
Balance on '/' is running
0 out of 1 chunks balanced (14 considered), 100% left
Dumping filters: flags 0x11, state 0x1, force is off
DATA (flags 0x2): balancing, usage=30
#
OK, Balancing läuft, das erkenne ich ... 100% left? Was soll das? Weil 0
von 1 chunk fertig ist? (Da kann ich mir die Prozentanzeige sparen.)
Es läuft offensichtlich nur Balancing auf DATA (weder Metadata noch
System) und der Filter ist 2 ... Was ist 2? ...
Und es sollten nur chunks betrachtet werden die zu höchstens 30% gefüllt
sind ...
Wer startet eigentlich dieses Balancing?
...
Ah ja, das steht in /etc/sysconfig/btrfsmaintenance ... und es gibt
einen systemd Service dazu ...
OK, also wohl ein automatisch ablaufender Wartungsjob ...
Es sind noch ~18,8% frei ('Device allocated' minus 'Used')
Sollte dusage dann nicht besser 82 sein?
So wie ich das verstehe ist das für alle Operationen ausreichend Platz.
Aber warum balanciert der da seit Tagen dran rum?
Wenn wenigstens irgendeine Art von Fortschritt zu sehen wäre ... aber
der Job frisst einfach nur CPU-Power und verursacht Waitstaites ...
... um das mal zum (vorläufigen?) Abschluss zu bringen ...
Nach Tagen des Wartens war es nun vorbei, nicht von selber, nein, ein
'btrfs balance cancel' half auch nicht und dann entschloss ich mich zu
einem Neustart. Auch der Shutdown dauerte minutenlang, bis das abhängen
der Devices endlich in einen Timeout lief und die Kiste sich abschaltete.
Nach dem Neustart scheint nun wieder alles 'normal' zu sein. Mal sehen
was beim nächsten, automatischen ... ah da fällt mir ein ich hatte in
/etc/sysconfig/btrfsmaintenance in BTRFS_BALANCE_PERIOD "none" statt dem
standartmäßigen "weekly" eingetragen. Ok, das habe ich nun auch wieder
entfernt und erneut gestartet. Noch ist alles im grünen Bereich. Mal
sehen wie lange ...
Bernd
--
Um die Liste abzubestellen, schicken Sie eine Mail an:
opensuse-de+unsubscribe(a)opensuse.org
Um den Listen Administrator zu erreichen, schicken
Sie eine Mail an: opensuse-de+owner(a)opensuse.org
Am Fri, 10 Apr 2020 10:46:46 +0200
schrieb Bernd Nachtigall <bnacht(a)web.de>de>:
Na ja, aber über 4 Stunden lang ... kann das sein? Hi,
in der letzten Woche gab es Updates u. a. im Bereich btrfs. In etwa
seit diesem Zeitpunkt bemerkte ich zwei Auffälligkeiten:
- Das Abschalten ist nicht erfolgreich.
Die GUI et.al. wird beendet, aber der Rechner bleibt irgendwie 'an'.
Die Hintergrundbeleuchtung des Monitors geht nicht aus und die LED
die den Zugriff auf die HDD (hier SSD) anzeigen soll, leuchtet dauern.
Bisher schalte ich dann nach einigen Minuten immer per Knopf ab.
- TOP zeigt dauernd eine CPU-Last grösser als 1 an.
Außerdem sind die wa immer über 1 (4-Core CPU). Auch zeigt iotop das
btrfs-balance dauernd storage-io verursacht. Dieser Prozess
(btrfs-balance steht im TOP aber auf State 'D'.
- journalctl zeigt viele Meldungen der Art:
BTRFS info (device dm-1) found 1 extends
(dm-1 scheint die root-partition zu sein.)
Ich würde gerne wissen was da los ist, hilfreiche Erläuterungen und
Tipps wo ich etwas finden könnte sind gerne gesehen.
Das sind vermutlich einerseits systemd Prozesse, die auf Beendigung des
Vorgänger-Prozesses warten, andererseits Indizierungen von BtrFS, denn
das sind ja copy on write Prozesse, für die ein Index erstellt oder
bereinigt werden muss. Hier ein paar Informationen dazu:
https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Copy_on_Write_.28CoW.…
320
days inactive
324
days old
3 comments
2 participants
participants (2)
-
Bernd Nachtigall -
Dieter Klünter