SystemD & *BSD & Linux auf älteren Systemen

[CommanderZed]

Wenn du highend Hardware hast und damit Bencharks machen willst ist das sicher korrekt. Wenn du auf lowend Hardware normale Usersachen machst ist das nicht relevant oder sogar irreführend.

Ja, das ist die perfekte Antwort. Ich glaube man kann sehr leicht sagen "für normale Workloads ist das Dateisystem sehr oft irrelevant".

(Es gibt - natürlich - immer ausnahmen)

Hier deswegen ein kleiner Punkt, es nützt nichts tiefgehende fachartikel zu lesen und dort dinge "aufzuschnappen" wenn man sehr wenig background zu den Themen hat, um diese breiter einzuordnen.

 

[Andy_m4]

So als Ergänzung / genauere Erklärung dessen was schon gesagt wurde:
Das ist ja generell ein Problem bei Benchmarks. Da steckt ja nicht nur der Effekt drin den man messen will, sondern es ist noch abhängig von der Hardware, vom der System, von der Konfiguration von der eigentlichen Software mit der Du testest/benchmarkst. Dann noch das Zusammenspiel all dessen, wo dann auch noch mal Dinge auftreten können, die man so nicht auf der Rechnung hatte.

Das ist ja ohnehin das grundlegende Problem was man bei Benchmarks hat. Das man ein relativ spezielles Setting hat mit dem man testen und versucht daraus aber allgemeine Aussagen (so a-la: Dateisystem A ist schneller als Dateisystem B) rauszuziehen.
Benchmarks taugen so oder so nur als grobe Richtschnur.

Im Idealfall testet man für sich selbst und mit seiner Hardware und Szenario und guckt, was da dann ggf. Verbesserungen bringt.

 

[cabriofahrer]

Nein, hast du nicht

Sorry, hatte mich vertan.

Grub kann nicht (nur eingeschrenkt) von btrfs booten, daher ist /boot auf ext4.

Aha, das ist die Erklärung, vielen Dank. Mit anderen Worten, die möchten also unbedingt ein System mit btrfs installieren und müssen aufgrund dieser Limitation extra eine zusätzliche Partition mit ext4 machen. Jetzt könnte man natürlich wieder anfangen zu diskutieren, ob diese Unzulänglicchkeit nun bei Grub oder bei btrfs zu sehen ist, bzw. wieder das Thema der Kohärenz und der In-Sich-Geschlossenheit eines Linux-Systems gegenüber eines BSDs starten... Aber lassen wir das besser.

Wo ist dein Problem mit der 512 MB großen /boot Partition?

Kein Problem. Wenn das eben (wegen btrfs) so sein muss. Aber wenn ich das jetzt richtig verstanden habe, könnte ich manuell mit ext4 alles auf eine Partition legen? Oder gibt es vielleicht einen anderen Vorteil oder Argument, warum man eine separate /boot Partition haben will?

Wenn du auf lowend Hardware normale Usersachen machst ist das nicht relevant oder sogar irreführend.

Nach meiner Erfahrung ist es gerade auf Low-End-Hardware nicht irrelevant, welches Dateiensystem man hat.

Im Idealfall testet man für sich selbst und mit seiner Hardware und Szenario und guckt, was da dann ggf. Verbesserungen bringt.

Sehe ich auch so. Aber trotzdem recherchiere ich im Vorfeld gerne, um zu wisssen, ob es nicht total abwegig erscheint.

 

[Andy_m4]

Jetzt könnte man natürlich wieder anfangen zu diskutieren, ob diese Unzulänglicchkeit nun bei Grub oder bei btrfs zu sehen ist

Grundsätzlich ist es ja das Konzept von GRUB Dateisysteme lesen zu können. Das war ja u.a. der große Schritt gegenüber LILO. LILO konnte keine Dateisysteme. LILO hast Du nur gesagt: An Platten-Sektor XYZ beginnt der Kernel. Lade mal von da. Das war einfach aber auch irgendwo doof. Weil jedesmal wenn man einen neuen Kernel hatte, musste man LILO Bescheid geben wo der liegt. Und dann konnte die Datei ja noch fragmentiert sein usw.
GRUB löste das Problem, in dem es Dateisysteme lesen kann. Das macht allerdings GRUB auch komplexer, weil Du halt ein Dateisystemtreiber mitschleppen musst.

Insofern ist das booten bei UEFI eigentlich ein ganz guter Kompromiss. Man hat halt ne standardisierte EFI-Partition mit standardisierten Dateisystem (FAT32). Man braucht letztlich nur noch seinen Kernel auf die EFI-Partition zu packen. Damit würde auch die von Dir angedeutete Diskussion "ists bei Linux besser oder bei BSD" obsolet. :-)

Aber trotzdem recherchiere ich im Vorfeld gerne, um zu wisssen, ob es nicht total abwegig erscheint.

Das ist ja auch alles in Ordnung.
Nur aus irgendeinem Grund schien wohl der Eindruck entstanden zu sein, das Du Benchmarks höher hängst als angemessen. :-)

 

[mr44er]

Vielleicht mal noch als Ergänzung nur ZFS betrachtet:

• Es ist oft lz4 default aktiviert, aber es muss nicht default im jeweiligen OS sein auf dem gebencht wird
• Nicht jedes Dateisystem pumpt viel in den RAM um davon zu profitieren. Hat man den cache 'warmlaufen' lassen, bevor gebencht wurde? Wurde zusätzlich ein extra-cache eingerichtet? etc.
• zstd verdrängt so langsam lz4, ist aber auch anspruchsvoller der CPU ggü. Mit den höheren Stufen noch viel mehr.
• Hat man einen pool aus reinen Magnetplatten, ist Kompression sehr sinnvoll. Dazu muss aber die CPU potent genug sein. Ist sie es nicht, würde man ohne Kompression wahrscheinlich besser fahren, man sollte genau das austesten.
• Hat man einen pool aus ultraschnellen NVME-SSDs, könnten die sogar schneller schreiben und lesen, als die CPU packen/entpacken kann. Auch hier wäre man ohne Kompression besser bedient, muss man auch testen.
• Manchem und je nach Einsatzzweck ist die Latenz viel wichtiger als der Nettodurchsatz
  

Benchmarks lesen ist ok, sollte aber immer nur ne Richtung zum Langhangeln vorgeben. Echte Werte bekommst du halt nur, wenn du es selber testest.

 

[medV2]

Sorry, hatte mich vertan.

Aha, das ist die Erklärung, vielen Dank. Mit anderen Worten, die möchten also unbedingt ein System mit btrfs installieren und müssen aufgrund dieser Limitation extra eine zusätzliche Partition mit ext4 machen. Jetzt könnte man natürlich wieder anfangen zu diskutieren, ob diese Unzulänglicchkeit nun bei Grub oder bei btrfs zu sehen ist, bzw. wieder das Thema der Kohärenz und der In-Sich-Geschlossenheit eines Linux-Systems gegenüber eines BSDs starten... Aber lassen wir das besser.

Früher waren zig Partitionen bei Linux gang und gebe. /boot / /usr /var /home waren durchaus üblich. Auch als ext4 kam, war lange eine /boot mit ext3 nötig, als xfs immer mehr standard wurde, gab es lange die /boot mit ext3/4.

Kein Problem. Wenn das eben (wegen btrfs) so sein muss. Aber wenn ich das jetzt richtig verstanden habe, könnte ich manuell mit ext4 alles auf eine Partition legen? Oder gibt es vielleicht einen anderen Vorteil oder Argument, warum man eine separate /boot Partition haben will?

Kannst du machen. Oder auch auf xfs. sogar auf btrfs, nur ist da etwas Handarbeit mit Grub nötig, und ich weiß nicht ob das in allen Konstallationen gut funktioniert.
Gibt aber auch andere Gründe für die extra /boot. So verschlüsselt Fedora soweit ich weiß auch bei einer Vollverschlüsselung das /boot nicht. /boot wird dann durch trusted boot Kette geschützt wenn gewünscht.

Grub KANN zwar auch von einer verschlüsselten Partition booten - aber wieder mit Einschrenkungen. Z.b. hast du nur das US Tastaturlayout - für Deutsche nicht so tragisch, aber es soll auch andere Sprachen mit deutlich mehr eigenen Zeichen geben. Die Keyderivation unter Grub ist deutlich langsamer, für eine Keyderivation die 3 Sek auf einem normalen System dauert, warte ich auf Grub also 10 Sec oder so.

Nach meiner Erfahrung ist es gerade auf Low-End-Hardware nicht irrelevant, welches Dateiensystem man hat.

Sehe ich auch so. Aber trotzdem recherchiere ich im Vorfeld gerne, um zu wisssen, ob es nicht total abwegig erscheint.

Filesystemtests auf 5000 Euro Hardware sagen dir dennoch wenig über deine 100 Euro Hardware aus. WENN dann müsstest du selbst testen.

 

[double-p]

Um mal den Bogen von Filesystemen zu "topic" systemd zu spannen:
systemd-repart(8). Das ist "borderline" oder "grenzgenial" (wie das meiste im systemd universe).

Der grosse Schmerz mit diesem Universum ist halt die Laptop/Desktop Fokusierung, die dann fragwuerdige
Entscheidungen hervorbringt. Ausserdem ist das ganze sehr stark ineinander verstrickt und mit "mal eben so"
faellt man dann auch mal hin.
Gepaart mit der EWONTFIX Einstellung ist das problematisch - oder war; ich bin mir da noch nicht gruen,
wie das mit den neuen Konstellationen langfristig wird.

 

[cabriofahrer]

Ich glaube, das Problem mit Fedora auf Hardware mit wenig RAM liegt ganz woanders: Swap on ZRAM, wie hier beschrieben:

Disk Configuration

Learn more about Fedora Linux, the Fedora Project & the Fedora Community.

docs.fedoraproject.org

Das mag ja für mit RAM ausreichend ausgestatteten Maschinen eine tolle und innovative Sache sein, aber man kann sich vorstellen, dass das bei nur 1 oder 2 GB RAM eher kontraproduktiv ist.
Da werde ich bei der nächsten Installation entweder eine Swap-Partition oder -File einrichten.

 

[Andy_m4]

Das mag ja für mit RAM ausreichend ausgestatteten Maschinen eine tolle und innovative Sache sein, aber man kann sich vorstellen, dass das bei nur 1 oder 2 GB RAM eher kontraproduktiv ist.

ZRAM ist eigentlich gerade für Rechner mit 1-2GB RAM interessant, weil durch die Kompression bewirkt wird, das dieser besser ausgenutzt wird.
Im Zweifel ist aber auch das eine Frage, wie man das am sinnvollsten konfiguriert.

 

[cabriofahrer]

Aha, und diese Kompression erfolgt "gratis", also ohne Rechnerleistung, die dann auf Kosten anderer Prozesse geht? Und was, wenn schlichtweg nicht genug RAM vorhanden ist?

 

[Andy_m4]

Aha, und diese Kompression erfolgt "gratis", also ohne Rechnerleistung

Nein. Natürlich nicht.
Im Grunde haben wir hier die gleiche Diskussion wie bei den Benchmarks auch. Ob es was bringt oder nicht oder kontraproduktiv ist, hängt von Deiner Hardware, von Deinen Settings und von Dein Anforderungsprofil ab.
Daher ist es immer schwierig irgendwie mit pauschalen Aussagen a-la "bei weniger als 2GB RAM ..." usw. zu hantieren.
Mehr will ich doch gar nicht gesagt haben.

Und was, wenn schlichtweg nicht genug RAM vorhanden ist?

Ja. Was ist, wenn nicht genug vorhanden ist oder gar vergessen wurde RAM einzubauen oder den Stecker in die Steckdose zu stecken. Dann könnt ihr euch all diese tollen Technologien in die Haare schmieren. °dreckig_lach°

 

[medV2]

Ich habe bei meinen PIs überall zswap mit lz4 aktiviert. Das komprimiert auch den RAM ist in der Umsetzung aber anders als zram.
Habe ich gute Erfahrungen gemacht, ABER: Ich nutze PIs nur als Server ohne GUI.

Zudem hab ich immer noch eine zusäztliche Swap Partition. Fedora legt default mäßig glaub ich nur noch zram an, weiß aber nicht ob es das automatisch entscheidet, je nachdem wieviel ram vorhanden ist.

 

[-Nuke-]

Jedes Smartphone verwendet übrigens zswap (oder vergleichbares). Statt die Daten auf den langsamen Datenträger auszulagern, lagert man sie in den RAM selbst aus. Jedoch komprimiert man die Daten vorher. Da sich RAM Inhalt in der Regel gut komprimieren lässt, passt in den Topf halt wesentlich mehr rein. Der Vorteil ist, dass man die Daten dort wieder recht schnell raus bekommt. Somit hält sich der Performance-Verlust in Grenzen.

Hilft natürlich nicht, wenn der RAM hinten und vorne nicht ausreicht. Dann wird auch wieder, sofern möglich, auf den Datenträger ausgelagert. zswap verbietet ja kein Swapspace auf dem Datenträger. Ist dann eben nachgelagert.

 

[vt9000]

Zu systemd und den ganzen Teilmodulen kann ich nicht viel dazu sagen, lediglich das ich wenig bis keine Probleme mit systemd bemerkt habe. Mein Berührungspunkt mit systemd beschränkt sich allerdings lediglich auf daemon-reload und einer Aktivierung des Dienstes via Ansible.

Arbeitstechnisch bin ich mittlerweile in der Containerisierung verortet. Hier hat systemd eine geringere Relevanz da lediglich Basisdienste via systemd verwaltet werden (postfix, ntpd), auf Infrastrukturservern noch zusätzlich named, squid, haproxy, ...

Der Rest läuft dann innerhalb Containern in k8s. Gefühlt hat sich dadurch die Bedeutung von systemd für das Service Management aus meiner Sicht minimiert.