• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Brtfs Probleme

blasius

Newbie
Feststellung:
Beim Einsatz von Qcad 3.7 verhielt sich opensuse 13.2 sonderbar. Der Bildschirm stand nach einiger Zeit bockstill, weder Maus noch Tastatur reagierten auf Eingaben. Ein Neustart (Reset) zeigte eine Liste von Aktionen, welche beim Modem-Manager stehen blieb. Also suse neu installiert. Lief einige Zeit wieder, dann nach Installation von Nvidia's Grafiktreiber die vorher beschriebene Situation. Ergo Neuinstallation aber mit Ext4 Dateisystem. Nun ist alles o.k.
Fazit:
Finger weg von Brtfs, wenn nicht eine 08/15 Situation vorliegt! :???:

PC-System: AMD PhenomII X4 sdb, sdc, sdd = Raid5 = /home XFS
sda1 = Windows 7 NTFS sde5 = Daten NTFS
sda2 = opensuse 13.2 Ext4 (Brtfs) sde6 = linux mint 17 Ext4
sda5 = Programme NTFS sde7 = mint /home XFS
sda6 = swap
(sda ist eine SSD)

Arbeits-Speicher 8 GB (2 Module)

Grafik: GeForce GT630

Bei einem Laptop mit Intel-Architektur, einer Brtfs-Systempartition und einer XFS-home-Partition gibt es diese Probleme nicht.
 

gehrke

Administrator
Teammitglied
blasius schrieb:
Fazit:
Finger weg von Brtfs, wenn nicht eine 08/15 Situation vorliegt! :???:
[...]
sda2 = opensuse 13.2 Ext4 (Brtfs)
Das geht mir etwas zu schnell. Welche Indizien hast Du denn, die auf BTRFS als Verursacher hindeuten - außer, dass das Verhalten mit ext4 (noch) nicht aufgetreten ist?

Und wie groß ist diese Partition?
 
OP
B

blasius

Newbie
Die Partition hat eine Grösse von 20 GB. Mit allen anderen Betriebs-Systeme (siehe Partitionstab.) gibt und gab es nie diese Probleme. Ein Hardwarefehler kann somit ausgeschlossen werden.
Alle Opensuse ab Version 9.1 liefen immer ohne solche Abstürze. Wenn etwas schief lief, liess sich wenigsten der Recovery-Modus starten.
Die Probleme gab es mit und ohne den nvidia-Treiber für die Grafikkarte. Ausserdem kann hier im Forum gelesen werden, dass Brtfs noch kein stabiles Datei-System ist!
Qcad als Ursache kann ausgeschlossen werden, weil sonst die anderen OS ebenfalls abgestürzt wären. Selbst in der Virtualbox mit opensuse 13.2 lief das Programm fehlerfrei.
Was liegt also näher als der Schluss: Brtfs ist die Ursache.
Item, wie auch immer, wer Probleme bei seinem opensuse mit Brtfs hat kriegt wenigsten einen Hinweis, wie diese vermieden werden können.
 

gehrke

Administrator
Teammitglied
blasius schrieb:
Ausserdem kann hier im Forum gelesen werden, dass Brtfs noch kein stabiles Datei-System ist!
Ich habe hier in jüngster Vergangenheit auch von einigen Leuten gelesen, dass das durchaus gut läuft. Bedenke bitte, dass sich die Leute typischerweise nur melden, wenn es Probleme gibt. Gemessen daran kann es gar nicht so schlecht sein.

Ich vermute mal, dass man hierfür mehr Speicherkapazität einplanen muss. Letztlich sind es die Snapshots, die für die Wiederherstellungspunkte benötigt werden. Bei jedem Update werden die alten Stände vorgehalten und je nach Konfiguration wächst das ganz gut an.

Ich habe deswegen beim Wechsel von ext4 auf btrfs die Kapazität von 20 auf 40 GB erhöht.
 

Sauerland

Ultimate Guru
Ich habe deswegen beim Wechsel von ext4 auf btrfs die Kapazität von 20 auf 40 GB erhöht.

Zitat Michael Kofler:
Update 6.11.2014: Die irrwitzige Anzahl der btrfs-Subvolumes hat anscheinend damit zu tun, dass Snapper die entsprechenden Verzeichnisse dann leichter von den automatisch erzeugten Snapshots ausnehmen kann. Eine vernünftige Dokumentation zur in openSUSE gewählten btrfs-Konfiguration habe ich bislang leider nicht gefunden. Sehr aufschlussreich ist aber immerhin das Snapper-Kapitel im Administrations-Handbuch zu SUSE Enterprise Linux 12:

https://www.suse.com/documentation/sles-12/pdfdoc/book_sle_admin/book_sle_admin.pdf

Spannend ist dieses Zitat (S. 38):

As a result, partitions containing snapshots need to be larger than “normal” partitions. The exact amount strongly depends on the number of snapshots you keep and the amount of data modifications. As a rule of thumb you should consider using twice the size than you normally would.

Mit anderen Worten: Das SLE-Handbuch empfiehlt, die root-Partition doppelt so groß wie bisher einzurichten, um den zusätzlichen Speicheraufwand von Snapper (+ btrfs) zu kompensieren!
https://kofler.info/opensuse-13-2-ausprobiert/
 
Eine Woche nach dem von Sauerland geposteten Zitat liefert Michael Kofler auf der gleichen Seite dann noch eine Lösungsmöglichkeit um den Speicherbedarf von Snapper zu dämmen:
Michael Kofler schrieb:
Update 13.11.2014: Durch das Script /etc/cron.daily/suse*-snapper wird die Anzahl der gespeicherten Snapshots auf maximal 10 reduziert. Die Parameter für das Aufräum-Script befinden sich in /etc/snapper/configs/root. Ihre Bedeutung ist in man snapper-configs dokumentiert. Der Platzbedarf durch die Snapshots sollte insofern überschaubar bleiben.
(https://kofler.info/opensuse-13-2-ausprobiert/)

Man kann Snapper wie alles in Linux individuell konfigurieren:
http://webapp5.rrz.uni-hamburg.de/SuSe-Dokumentation/manual/sles-admin_de/cha.snapper.html
https://de.opensuse.org/SDB:Snapper
https://www.bitblokes.de/2014/11/bt...se-13-2-nutzen-keine-konfiguration-vorhanden/
 

gehrke

Administrator
Teammitglied
Ja, allerdings empfiehlt SUSE für SLES 11.3:
TIPP: Größe der Btrfs-Partition
Die gespeicherten Snapshots belegen mehr Speicherplatz. Es wird
daher empfohlen, eine größere Speichermenge für die Btrfs-Partition zu
reservieren als für eine Partition, auf der keine Snapshots angefertigt
werden können (z. B. Ext3). Für eine Btrfs-Root-Partition mit den
vorgeschlagenen Subvolumes wird 20 GB Speicherplatz empfohlen.
https://www.ostc.de/public/datev/doc-sles11-sp3/de/deployment.pdf

20G sind aber genau das, was der TE zur Verfügung hatte. Das ist etwas wiedersprüchlich, aber wenn man sehr viel Zeug installiert hat, dann kann das wohl auch schnell knapp werden.
 
@gehrke:
Die Lösung neben größerer Root-Partition: Snapper konfigurieren!

Übrigens habe ich jüngst in folgenden threads neben Snapper/Snapshots von einer weiteren Problematik in Zusammenhang mit Btrfs und Festplattenüberlauf gehört: Metadaten.

http://forum.linux-club.de/viewtopic.php?f=89&t=120031
http://www.opensuse-forum.de/allgem...on-device-obwohl-6-8-gb-platz-ist/index3.html
--> insbesondere post #30!
https://forums.opensuse.org/showthread.php/503867-no-space-left-on-device-opensuse-13-2

Was es genau damit auf sich hat: ??? :???:
Würde mich sehr interessieren was das für Metadaten sind von denen da die Rede ist!
 

gehrke

Administrator
Teammitglied
@linux-freund: Danke für die Links.

BTW: Wie bekommt man eigentlich auf der Kommandozeile angezeigt, wie viel Speicherkapazität von den Snapshots belegt werden?
TNX
 
gehrke schrieb:
BTW: Wie bekommt man eigentlich auf der Kommandozeile angezeigt, wie viel Speicherkapazität von den Snapshots belegt werden?
TNX
Wüsste ich auch gerne ;)
Ich habe es als Root versucht mit
Code:
du -sh .snapshots
Ergebnis: 85G :eek:0:
Absolut unmöglich, da meine Root-Partition gerade mal 40 Gb hat!
 
Tja, also die Dateigröße der Snapshots zu ermitteln scheint aktuell noch ein Problem zu sein.
Das ist wirklich nich so dolle und sollte zukünftig unbedingt verbessert werden!
 
@tomm.fa:
Code:
linux-druf6:/ # btrfs subvolume list -s /
ID 324 gen 1304 cgen 1304 top level 275 otime 2014-12-05 15:43:16 path .snapshots/47/snapshot
ID 325 gen 1307 cgen 1306 top level 275 otime 2014-12-05 15:44:09 path .snapshots/48/snapshot
ID 363 gen 2093 cgen 2092 top level 275 otime 2014-12-22 17:46:59 path .snapshots/86/snapshot
ID 364 gen 2098 cgen 2097 top level 275 otime 2014-12-22 17:48:42 path .snapshots/87/snapshot
ID 432 gen 4620 cgen 4619 top level 275 otime 2015-01-14 22:08:05 path .snapshots/154/snapshot
ID 433 gen 4623 cgen 4622 top level 275 otime 2015-01-14 22:08:51 path .snapshots/155/snapshot
ID 434 gen 4647 cgen 4647 top level 275 otime 2015-01-18 01:03:02 path .snapshots/156/snapshot
ID 435 gen 4650 cgen 4649 top level 275 otime 2015-01-18 01:03:50 path .snapshots/157/snapshot
ID 436 gen 4653 cgen 4652 top level 275 otime 2015-01-18 01:04:26 path .snapshots/158/snapshot
ID 437 gen 4658 cgen 4657 top level 275 otime 2015-01-18 01:06:40 path .snapshots/159/snapshot
ID 438 gen 4780 cgen 4779 top level 275 otime 2015-01-28 19:12:45 path .snapshots/160/snapshot
ID 439 gen 4782 cgen 4781 top level 275 otime 2015-01-28 19:13:13 path .snapshots/161/snapshot
ID 440 gen 4836 cgen 4835 top level 275 otime 2015-01-28 19:55:57 path .snapshots/162/snapshot
ID 442 gen 4843 cgen 4842 top level 275 otime 2015-01-28 19:58:54 path .snapshots/163/snapshot
ID 443 gen 4968 cgen 4968 top level 275 otime 2015-02-08 18:25:23 path .snapshots/164/snapshot
ID 444 gen 4983 cgen 4982 top level 275 otime 2015-02-08 18:32:38 path .snapshots/165/snapshot
ID 445 gen 5023 cgen 5022 top level 275 otime 2015-02-08 19:07:33 path .snapshots/166/snapshot
ID 446 gen 5058 cgen 5057 top level 275 otime 2015-02-08 19:38:16 path .snapshots/167/snapshot
Auch nix!
 
Danke für den äußerst interessanten link, tomm.fa!

Folgende Ausgabe habe ich erhalten:
Code:
linux-druf6:/ # btrfs filesystem df .snapshots
Data, single: total=8.01GiB, used=7.87GiB
System, DUP: total=8.00MiB, used=16.00KiB
System, single: total=4.00MiB, used=0.00B
Metadata, DUP: total=1.00GiB, used=666.17MiB
Metadata, single: total=8.00MiB, used=0.00B
GlobalReserve, single: total=192.00MiB, used=0.00B
Mit dem Befehl btrfs filesystem df -h .snapshots ging es nicht ... "too many arguments".
Ich musste "-h" weglassen dann hat es funktioniert.

Werde bei Gelegenheit mal mit den im link genannten Befehlen experimentieren.
 

Kurt M

Hacker
nachdem ich auf 3 PCs und ein Freund auf einem Notebook in die gleiche btrfs Falle liefen (bei Partitionen weit über 20GB Größe) hab ich mir den Stress nicht gemacht.
Einfach mit ext4 neu installiert, die Systeme laufen seitdem völlig problemlos.
 
@Kurt M:
"btrfs Falle".. was für ein fürchterliches Geschwätz!
Neues Dateisystem > Neue Möglichkeiten, aber auch neue Befehle, Config-Dateien etc..
Btrfs hat eigene Befehle und eigene Bedingungen, wie jedes andere Filesystem auch.
Lernen und verstehen statt mies zu machen sage ich dazu!
 
@josef-wien:
Die default-Einstellungen für die Größe der Root-Partition und die Automatisierung von Snapper führen zu diesem Problem und sind nicht gut das hatten wir bereits erkannt.
Ich persönlich bin selbst noch Anfänger und habe nachdem ich von der Problematik gehört hatte einfach die Root-Partition größer eingerichtet (40GB) und später auch noch die Snapper-Automatisierung abgeschaltet. Obwohl ich bei 40GB nie auch nur ansatzweise in die Nähe einer vollen Root-Partition gekommen war.
Alleine eine größere Root-Partition sollte also schon ausreichen und Ruhe ist mit "btrfs-Falle", dann braucht man die Automatisierung noch nicht mal abschalten.
Was ist daran so schwierig und kompliziert?
Da finde ich es schwerer openSUSE neben Windows8.1 auf einem UEFI-PC mit Secure-Boot zu installieren und da muss heute jeder Anfänger bei PC-Neukauf durch!
 
Oben