V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
Developer92 schrieb: CoW ist immer da ein Performance-Fresser, wo innerhalb einer bestehenden Datei immer wieder Bereiche geändert werden. Und gerade bei den genannten Dingen ist das innerhalb kurzer Zeit sehr oft der Fall, weshalb die Performance mit Copy-on-Write gegen Null geht.
Danke für die Erläuterung. ☺
Früher™ hatte man zwei bis drei Layer (bspw. RAID → LVM → Dateisysteme), welche nun mit einem einzigen Dateisystem erschlagen werden.
Verstößt das nicht gegen „one job, one tool“?
Moderiert von redknight: Wegen epischer Länge abgetrennt 😉
|
redknight
Moderator & Supporter
Anmeldungsdatum: 30. Oktober 2008
Beiträge: 21736
Wohnort: Lorchhausen im schönen Rheingau
|
V_for_Vortex schrieb: Verstößt das nicht gegen „one job, one tool“?
Kommt drauf an, wie du den Job definierst 😉 Der Job könnte je nach Sicht sein "Schreibe eine Datei" - da wäre btrfs/zfs näher an one job, one tool.
|
Developer92
Anmeldungsdatum: 31. Dezember 2008
Beiträge: 4101
|
V_for_Vortex schrieb: Developer92 schrieb: Früher™ hatte man zwei bis drei Layer (bspw. RAID → LVM → Dateisysteme), welche nun mit einem einzigen Dateisystem erschlagen werden.
Verstößt das nicht gegen „one job, one tool“?
Komisch, heut früh kam mir genau der gleiche Gedanke. Allerdings habe ich noch keine direkte Antwort darauf gefunden. Einerseits muss man sagen: Ja, btrfs versucht vieles zu vereinen, wo man bisher jeweils ein eigenständiges Werkzeug zur Hand hatte. Andrerseits bedeutet das aber auch, dass ich mich in Zukunft nicht mehr mit drei Werkzeugen auskennen muss (mdadm, lvm2, ext4), sondern nur noch mit einem (btrfs). Fragt sich auch, ob man RAID, LVM und Dateisystem wirklich als getrennte "Aufgaben" ansehen sollte, oder ob vielleicht auch einfach nur die bisherige Sichtweise "falsch" war, weil es sich eben historisch so entwickelt hat. Abgesehen davon hat man aber auch noch andere Vorteile, die mit getrennten Layern nicht möglich wären. Bei einem Plattenausfall meines RAIDs mussten bisher all meine Platten komplett gelesen werden, damit daraus dann die neue Platte, welche die defekte ersetzt, erstellt werden konnte (ausgehend von RAID5). Bei btrfs hingegen müssen nur so viele Daten gelesen werden, wie tatsächlich zum Wiederherstellen der neuen Platte nötig sind. Wenn das RAID also nur zu 30% befüllt war brauche ich auch nur von jeder Festplatte 30% der Daten lesen (bei RAID5, bei anderen RAID-Leveln sieht es wieder anders aus). Ich kann auch im Betrieb RAID-Level wechseln (bevor jemand fragt: Hab ich ausprobiert, hat funktioniert, kann sogar unterbrochen und später wieder fortgeführt werden [und ja, das hab ich auch ausprobiert]). Das dürfte mit Hardware-RAID relativ schwierig werden (oder geht das vielleicht doch? Ich muss zugeben, ich hab davon nicht wirklich Ahnung). Wenn man Subvolumes als Ersatz für LVM nimmt (auch wenn man das eigentlich™ nicht so direkt vergleichen kann, weil die Funktionen zwar ähnlich, aber nicht identisch sind) hat man auch hier eine höhere Flexibilität: Wenn ich ein ext4-Dateisystem innerhalb eines LVMs verkleinern wollte, weil ich eine andere Partition vergrößern wollte, ging das nur über aushängen der Partition, verkleineren der Partition, anpassen von LVM, vergrößern der anderen Partition und wiedereinhängen der ausgehängten Partition. Bei Subvolumes ändere ich, sofern ich überhaupt etwas ändern muss, nur die Quotas. Fertig. Wobei ich das bisher auch erst ein- bis zweimal machen musste durfte, insofern relativiert sich der Aufwand wieder.
|
encbladexp
Ehemaliger
Anmeldungsdatum: 16. Februar 2007
Beiträge: 17449
|
One Job, one Tool. Alles ist eine Datei. Es gibt unzählige alte Konzepte die in der modernen Welt wohl langsam als überholt gelten dürfen. ZFS und btrfs zeigen das man auch ohne LVM und Linux Software RAID sehr erfolgreich sein kann. Wichtig ist, das neue Lösungen deutliche Vorteile gegenüber bestehende Lösungen bieten, sonst lohnt sich die Abweichung von alten Pfaden nur bedingt. Die Kommunikation über diverse Schichten, von der Platte zur Datei ist im bewährten Konzept durch viele Layer geprägt. Wenn es schlecht läuft ungefähr so:
Festplatte Linux Software RAID dm-crypt/LUKS Logical Volume Manager Volume mit Dateisystem
Mit ordentlich Arbeit an den Layern hat man es geschafft das ein TRIM bei diesem Konstrukt weitgehend möglich ist. Jedoch sind einige andere Dinge nur schwer möglich, wie eben das schnellere Rebuild vom RAID (nur Transfer der Nutzdaten). Eine Deduplication möchte ich mir bei genanntem Stack nicht im Ansatz vorstellen. Doch gleichzeitig hat oben genannter Stack noch lange nicht ausgedient, sei es wegen der aktuell besseren Stabilität, als Datengrab für virtuelle Maschinen oder einfach weil man sich an diese Tools gewöhnt hat. ZFS, btrfs, systemd… alles Dinge welche einige bis viele der alten Konzepte in Frage stellen. Ich selbst habe dabei entschieden mich auf diese "schöne neue Welt" einzulassen, beachte aber dabei immer das neuer nicht unbedingt besser sein muss. Bis ich mir systemd angeschaut habe sind 1-2 Jahre vergangen, vorher war der Mehrwert noch rudimentär. Das Dateisystem btrfs kommt seit ~1 Jahr regelmäßiger zum Einsatz, ebenfalls mit positiven Erfahrungen. ZFS kommt zumindest hier lokal erst zur Diskussion wenn dies in einem vanilla Kernel enthalten ist 😉 mfg Stefan Betz
|
glasenisback
Anmeldungsdatum: 20. November 2011
Beiträge: 1603
Wohnort: Fernwald (Gießen)
|
V_for_Vortex schrieb: Verstößt das nicht gegen „one job, one tool“?
Unix ist keine Religion und "one job, one tool" kein feststehendes Dogma.
|
V_for_Vortex
(Themenstarter)
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
glasenisback schrieb: V_for_Vortex schrieb: Verstößt das nicht gegen „one job, one tool“?
Unix ist keine Religion und "one job, one tool" kein feststehendes Dogma.
Es ist Teil der sogenannten Unix-Philosophie, ähnlich wie das von encbladexp erwähnte Alles ist eine Datei. Insofern ist eine augenscheinliche Abweichung davon durchaus hinterfragbar, zudem es keine rein willkürliche Tradition ist, sondern nach dem KISS-Prinzip Systeme einfach halten soll(te). Ebenso hinterfragbar ist natürlich das Zeitgemäße dieser Philosophie oder der sie umsetzenden Programme. redknight schrieb: Kommt drauf an, wie du den Job definierst 😉 Der Job könnte je nach Sicht sein "Schreibe eine Datei" - da wäre btrfs/zfs näher an one job, one tool.
Es ist eine Definitionsfrage, aber keine völlig freie. So liefe jedes Betriebssystem damit konform, weil es den Job „betreibe den Computer“ erledigt. 😉 Developer92 schrieb: Wenn ich ein ext4-Dateisystem innerhalb eines LVMs verkleinern wollte, weil ich eine andere Partition vergrößern wollte, ging das nur über aushängen der Partition, verkleineren der Partition, anpassen von LVM, vergrößern der anderen Partition und wiedereinhängen der ausgehängten Partition.
Zudem auch noch das Anpassen des Dateisystems und eines eventuellen Krypto-Containers. Partition und Container fallen auch bei btrfs an, der Rest wird deutlich gestrafft. encbladexp schrieb: Die Kommunikation über diverse Schichten, von der Platte zur Datei ist im bewährten Konzept durch viele Layer geprägt.
Das kann wie im Beispiel von TRIM hinderlich sein, hat generell aber auch Vorteile, wie das Austauschen oder Weglassen einzelner Layer.
ZFS, btrfs, systemd… alles Dinge welche einige bis viele der alten Konzepte in Frage stellen. Ich selbst habe dabei entschieden mich auf diese "schöne neue Welt" einzulassen, beachte aber dabei immer das neuer nicht unbedingt besser sein muss.
Meine Frage war auch keine Kritik, sondern nur ein Punkt, der mir bei Developer92s Worten in den Kopf kam. Alles fließt und ich finde die Entwicklung neuen Technologien sehr spannend. Danke Euch allen für Eure Gedanken!
|
redknight
Moderator & Supporter
Anmeldungsdatum: 30. Oktober 2008
Beiträge: 21736
Wohnort: Lorchhausen im schönen Rheingau
|
V_for_Vortex schrieb: redknight schrieb: Kommt drauf an, wie du den Job definierst 😉 Der Job könnte je nach Sicht sein "Schreibe eine Datei" - da wäre btrfs/zfs näher an one job, one tool.
Es ist eine Definitionsfrage, aber keine völlig freie. So liefe jedes Betriebssystem damit konform, weil es den Job „betreibe den Computer“ erledigt. 😉
Du vergleichst Äpfel mit Birnen, abstrakte mit konkreten Aufgaben. "Schreibe/Lese eine Datei" ist eine konkrete Aufgabe, die auch jetzt schon von der Abstraktionsschicht VFS erledigt wird. Ob und an welche weitere Schicht sich VFS wendet, ist für den User a) egal und b) nicht nachvollziehbar, von daher bleibt "one job, one tool" durchaus gewahrt.
|
V_for_Vortex
(Themenstarter)
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
redknight schrieb: Du vergleichst Äpfel mit Birnen, abstrakte mit konkreten Aufgaben. "Schreibe/Lese eine Datei" ist eine konkrete Aufgabe, die auch jetzt schon von der Abstraktionsschicht VFS erledigt wird. Ob und an welche weitere Schicht sich VFS wendet, ist für den User a) egal und b) nicht nachvollziehbar, von daher bleibt "one job, one tool" durchaus gewahrt.
btrfs erledigt aber viel mehr als nur eine Datei zu lesen/schreiben und erledigt Aufgaben, die früher anderen Tools vorbehalten waren. Ist Dein Beispiel insofern ein Herauspicken eines Apfels aus einem Obstkorb? Wo wäre bei einem Dateisystem für Dich die Grenze eines Jobs? Wäre eine weitere Funktionserweiterung mit z.B. denen eines Dateimanagers immer noch der Job „Schreibe/Lese eine Datei“?
|
redknight
Moderator & Supporter
Anmeldungsdatum: 30. Oktober 2008
Beiträge: 21736
Wohnort: Lorchhausen im schönen Rheingau
|
V_for_Vortex schrieb: redknight schrieb: Du vergleichst Äpfel mit Birnen, abstrakte mit konkreten Aufgaben. "Schreibe/Lese eine Datei" ist eine konkrete Aufgabe, die auch jetzt schon von der Abstraktionsschicht VFS erledigt wird. Ob und an welche weitere Schicht sich VFS wendet, ist für den User a) egal und b) nicht nachvollziehbar, von daher bleibt "one job, one tool" durchaus gewahrt.
btrfs erledigt aber viel mehr als nur eine Datei zu lesen/schreiben und erledigt Aufgaben, die früher anderen Tools vorbehalten waren.
Das ist richtig. Jerdes andere Dateisystem erledigt allerdings auch mehr als lesen und schreiben. Aber deine Aufgabe übergibst Du als user dem VFS. Von daher bleibt dein Tool gleich, nämlich VFS 😉 Ist Dein Beispiel insofern ein Herauspicken eines Apfels aus einem Obstkorb?
Das verstehe ich nicht. Worauf willst du hinaus? Wo wäre bei einem Dateisystem für Dich die Grenze eines Jobs?
Das Dateisystem stellt die nötigen Funktionen der Abstraktionsschicht VFS zur Verfügung. Auch NFS und SMB erweitern die Funktionen eines Dateisystems gewaltig, um Netzwerkzugriff zum Beispiel.
|
V_for_Vortex
(Themenstarter)
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
redknight schrieb: Das ist richtig. Jerdes andere Dateisystem erledigt allerdings auch mehr als lesen und schreiben.
Weshalb ich Dein Beispiel „Schreibe/Lese eine Datei“ auch unpassend fand und daher hinterfragte. ☺
Aber deine Aufgabe übergibst Du als user dem VFS. Von daher bleibt dein Tool gleich, nämlich VFS 😉
Vielleicht ein Missverständnis: Ich sprach nicht von der Benutzerbene. Auf der könnte man ansonsten auch noch einen Dateimanager ins Dateisystem integrieren und es wäre immer noch „ein Job“. Auch das Betriebssystem benötigt der Benutzer für das Schreiben einer Datei, denn ohne es kann er oder sie es nicht. Daher auch mein ins Extreme weitergedachter Vergleich mit dem „einen Job“ eines BS – für die wahrscheinlich letztlich philosophische Frage, wo die Grenze eines Jobs ist.
Ist Dein Beispiel insofern ein Herauspicken eines Apfels aus einem Obstkorb?
Das verstehe ich nicht. Worauf willst du hinaus?
Ich habe da sinnbildlich Deine Äpfel und Birnen in einen Korb gelegt. ☺ Gemeint war: Du nimmst eine Funktion unter mehreren als Beispiel für einen Job des Tools. Jetzt ist klar, dass Du damit „aus Benutzersicht“ meintest, ich meinte aber alle Jobs eines Tools, nicht nur die ersichtlichen, zudem sich das Ersichtliche je nach Wissensstand des Nutzers stark verändert. Das betreffende Unix-Prinzip heißt ja auch nicht „one apparent job, one tool“.
Wo wäre bei einem Dateisystem für Dich die Grenze eines Jobs?
Das Dateisystem stellt die nötigen Funktionen der Abstraktionsschicht VFS zur Verfügung. Auch NFS und SMB erweitern die Funktionen eines Dateisystems gewaltig, um Netzwerkzugriff zum Beispiel.
Richtig, auch da könnte man diese Frage stellen. Btrfs vereint Funktionen mehrerer früherer Tools und mir stellte sich die Frage, ob und wo es nicht mehr dem traditionellen Prinzip entspricht (ohne Aussage, ob es das müsste, oder sonstige Bewertung). Und die Frage gab ich an Euch weiter. ☺
|
redknight
Moderator & Supporter
Anmeldungsdatum: 30. Oktober 2008
Beiträge: 21736
Wohnort: Lorchhausen im schönen Rheingau
|
V_for_Vortex schrieb: redknight schrieb: Das ist richtig. Jerdes andere Dateisystem erledigt allerdings auch mehr als lesen und schreiben.
Weshalb ich Dein Beispiel „Schreibe/Lese eine Datei“ auch unpassend fand und daher hinterfragte. ☺
Daher stand im Text davor ja auch redknight schrieb: Kommt drauf an, wie du den Job definierst 😉 Der Job könnte je nach Sicht sein "Schreibe eine Datei" - da wäre btrfs/zfs näher an one job, one tool.
Aber deine Aufgabe übergibst Du als user dem VFS. Von daher bleibt dein Tool gleich, nämlich VFS 😉
Vielleicht ein Missverständnis: Ich sprach nicht von der Benutzerbene.
Ich verstehe nicht, was du meinst. Wenn VFS nicht benutzt wird, schreibst Du Rohdaten auf ein Device. Welche ebene gibt es denn bei dir noch? Auf der könnte man ansonsten auch noch einen Dateimanager ins Dateisystem integrieren und es wäre immer noch „ein Job“.
Ich verstehe nicht, was Du mit dem Dateimanager willst. Dieser dienst zur Anzeige eines Inhalts und fragt *trommelwirbel* das VFS ab. Auch das Betriebssystem benötigt der Benutzer für das Schreiben einer Datei, denn ohne es kann er oder sie es nicht.
Du vergleichst wieder abstraktes mit konkretem. Die Aufgabe des Kernels ist es eben, Funktionen und Hardwarezugriffe etc zu abstrahieren. Wenn wir auf die Art diskutieren kann ich sagen, der einzige Job ist "Power on" zu drücken, denn ohne die Ausführung geht es nicht. Das ist aber nicht die Grundlage der Aussage. Genauso wie nebebei "Never touch a running system" nicht aussagt, dass man das System nicht verändern sollte, nur dass man Veränderungen nicht im running state vornimmt, also Wartungszyklen dafür hernimmt. Daher auch mein ins Extreme weitergedachter Vergleich mit dem „einen Job“ eines BS – für die wahrscheinlich letztlich philosophische Frage, wo die Grenze eines Jobs ist.
Was in meiner ursprünglichen Aussage auch dabeistand. Siehe oben. Ich habe da sinnbildlich Deine Äpfel und Birnen in einen Korb gelegt. ☺ Gemeint war: Du nimmst eine Funktion unter mehreren als Beispiel für einen Job des Tools. Jetzt ist klar, dass Du damit „aus Benutzersicht“ meintest, ich meinte aber alle Jobs eines Tools, nicht nur die ersichtlichen, zudem sich das Ersichtliche je nach Wissensstand des Nutzers stark verändert. Das betreffende Unix-Prinzip heißt ja auch nicht „one apparent job, one tool“.
Ok. Früher(tm), die Älteren werden sich noch erinnern, musste man Dateisysteme mal defragmentieren. Das muss man bei neueren Dateisystemen nicht mehr, da sie entsprechende Berechnungen, wo es möglich ist, bereits beim schreiben einer Datei vornehmen. Für mich gehört so was zum Job "schreibe eine Datei", denn es ist mir egal, ob jemand anderes defraagmentieren muss oder nicht. Das gilt nicht nur für mich als physikalischen "Nutzer", auch Systemnutzern bzw Diensten ist es herzlich egal. Der Job, den die weitergeben, ist lediglich "write a file".
|