Login
Newsletter
Werbung

Thema: DragonFly BSD setzt auf Hammer 2

10 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Anon Y. Mouse am Do, 13. Juni 2019 um 21:14 #

HAMMER und HAMMER2 auf Linux zu portieren?

Wäre sicherlich interessant neben ZFS (Lizenzprobleme) und BTRFS (Zuverlässigkeit) und bcachefs (noch nicht fertig) noch ein paar weitere Spielwiesen zu haben. Eines muss ja dann mal was werden :-)

[
| Versenden | Drucken ]
  • 0
    Von kraileth am Do, 13. Juni 2019 um 22:11 #

    Es hat verschiedene Versuche gegeben, HAMMER auf andere BSDs zu portieren - so richtig ernsthaft scheint davon aber nichts gewesen zu sein, denn ein Durchbruch wurde meines Wissens ebenso wenig erzielt wie ein bestimmtes Problem beschrieben wurde. Vielmehr ist wohl alles sang- und klanglos eingeschlafen. Laut Dillon ist eine Portierung von HAMMER1 selbst auf FreeBSD nicht ganz ohne (DragonFly hat sich abgespalten, bevor FreeBSD im Zuge der großen Umbauten für 5.x das geniale GEOM-Framework erhielt und funktioniert in Sachen Festspeicher daher ziemlich anders).

    Auf der anderen Seite soll HAMMER2 deutlich portabler sein und für die Verschlüsselung hat man LUKS auf DragonFly portiert. Aber Dateisysteme sind kein Spaß - wenn eines zu etwa 99% funktioniert, muß man das konsequent als "funktioniert nicht" werten, da man ihm keine Daten anvertrauen darf (oder den Gesichtsverlust und damit einhergehend den schlechten Namen riskieren, den sich BTRFS verdient hat). Allerdings scheinen selbst die Ansätze mit FUSE, die ich vor ein paar Jahren beobachtet hatte, scheinen nicht gefruchtet zu haben.

    Insgesamt ist es aber sehr schade, daß HAMMER eine reine DF-Insel ist. Es hat ein paar ziemlich nette Fähigkeiten - die feinkörnige History / ständigen automatischen (!) Snapshots stecken in diesem Fall sogar ZFS in die Tasche. Wenn ZFS sein ganzes Arsenal auffährt, kann HAMMER natürlich nicht mithalten. Das ist aus meiner Sicht aber auch gar nicht nötig, da es einen ganz anderen Ansatz verfolgt. Dazu ist es im Gegensatz zum notorisch speicherhungrigen ZFS ziemlich genügsam.

    Ich würde nicht ungern zumindest eine Umsetzung via FUSE sehen. Richtig nett wäre natürlich eine native Implementierung z.B. in FreeBSD und Linux. Sollte das geschehen würde ich definitiv mehr als mal wieder einen Blick riskieren (DF kommt für mich leider aus verschiedenen Gründen nicht als Primärsystem in Frage).

    [
    | Versenden | Drucken ]
    • 1
      Von blablabla233 am Fr, 14. Juni 2019 um 08:49 #

      Frage:
      Was sind die Gruende DF nicht als BS zu nutzen?
      Auf Laptop geht es bei mir wunderbar (dank der aktuellen Intel-Gpu-Treiber) auf Servern habe ich aber FreeBSD

      [
      | Versenden | Drucken ]
      • 1
        Von klopskind am Fr, 14. Juni 2019 um 12:03 #

        Je nachdem, wen Sie fragen, werden Sie unterschiedliche Antworten erhalten.

        Wenn es allein um den Einsatz auf Laptops in der Gegenwart geht, sprächen diejenigen Gründe gegen einen Einsatz von DragonFly BSD, bei denen es Alternativen derzeit hinterherhinkt. Meiner Meinung nach betrifft das nicht nur ausschließlich folgende Punkte:
        a) zeitnahe, vollständige und breite Unterstützung aktueller Hardware
        b) fehlerfreie Unterstützung und Ausnutzung von modernen Energiesparmechanismen mit ähnlichen oder besseren Resultaten
        c) Softwarekompatibilität & -angebot (nicht einmal TeXLive 2018, geschweige denn 2019, liegt in den DPorts; es liegt nicht mal in den FreeBSD Ports, von denen die DPorts abgeleitet sind)
        d) stabile Schnittstellen, Middleware, Bibliotheken und Toolkits
        e) umfangreiche und sinnvolle Tests
        f) Umstiegs- & Einrichtungsaufwand (setzt voraus, dass Nutzer Dragonfly BSD als Alternative kennen)
        g) Dokumentation & Hilfe
        h) Nutzerbasis -> Hilfe von Dritten & Anwendungs-/Testfeld
        i) Entwicklungszyklen/-fortschritt, Langzeitunterstützung
        j) Verlässlichkeit, Sicherheit & Nachhaltigkeit (Erhaltungskonzept, Fortbestand, Ressourcen, Investitionen, Entwicklung, Forschung)
        k) Bedienungskonzept (z.B. kein festgelegtes GUI); generell werden viele Entscheidungen und deren Umsetzung auf den Benutzer abgewälzt (Freiheit und Aufwand vs. Zweckdienlichkeit und Bequemlichkeit)
        l) Performance

        Ohne Anspruch auf Vollständigkeit belasse ich es zunächst bei dieser Liste. Es gibt sicherlich noch ganz andere Punkte und Facetten. Und sicherlich sind darunter auch einige subjektive Aspekte und Begründungen, die individuell abweichen oder gewichtet werden können.

        Dass es Gründe gibt, die den Einsatz rechtfertigen, oder dass es Laptops gibt, auf denen DragonFly BSD zufriedenstellend läuft, möchte ich hiermit nicht bestreiten. Und es gibt sicherlich Nutzer, für die der Einsatz von DragonFly BSD auf ihrem Laptop ein (lokales) Optimum darstellt. Aber das ist eine andere Geschichte...

        [
        | Versenden | Drucken ]
        • 0
          Von kraileth am Fr, 14. Juni 2019 um 15:57 #

          Ihrer Zusammenfassung stimme ich in Hinblick auf die Allgemeinheit zu. Da es sich um ein Nischen-BS handelt, sind aber sicher einige der Punkte für die potentielle Zielgruppe wichtiger als andere. Wenn ich wirklich DF will und weiß, daß Dillon gerade viel mit Ryzen-Prozessoren gemacht hat, dann beschaffe ich eventuell entsprechende Hardware. Punkt b kann man, je nach Anforderungen, bestimmt auch ignorieren. Haarig wird's bei c...

          TeX auf FreeBSD ist eine ganz eigene Geschichte - und leider keine besonders gute (trotz durchaus vorhandenem „Gruselfaktor“...). Die Kurzfassung auf meiner FreeBSD-Arbeitsstation sieht so aus (Ports-Baum auf dem Stand von gestern morgen):

          % cat /usr/ports/print/texlive-base/distinfo
          SHA256 (TeX/texlive-20150521-source.tar.xz) = ed9bcd7bdce899c3c27c16a8c5c3017c4f09e1d7fd097038351b72497e9d4669
          SIZE (TeX/texlive-20150521-source.tar.xz) = 45459552

          Absolut unbefriedigend - zumal es über die Jahre immer wieder Alternativen gab, die dann aber nicht im Ports-Baum gelandet sind! Egal. Am Wochenende landet mit „zziplib“ die letzte Laufzeit-Abhängigkeit für TeXLive in Raven, versprochen. Sollte ich mich nicht vertan haben, fehlen dann nur noch zwei weitere Pakete, die ich mir auch mal anschauen will. Vielleicht wird das aus dieser Richtung ja noch was mit TeX...

          Die meisten anderen Punkte sind sicherlich für den einen mehr und für den anderen weniger ausschlaggebend. Bei Punkt l stutze ich allerdings. So weit ich weiß, legt DF gerade auf die Performance extrem hohen Wert und macht dabei keine schlechte Figur.

          Was ich zusätzlich noch schade finde, ist das völlige Fehlen anderer Architekturen. Natürlich ist amd64 absolut bestimmend und die Entwicklergemeinde zu klein, um i386 erfolgreich fortzuführen oder an aarch64 zu tüfteln (woran FreeBSD gerade genug zu knabbern hat). Trotzdem hätte gerade das in Bezug auf die Qualität einen großen Nutzen. Dabei bin ich ein großer Freund der Strategie von OpenBSD, die ihr System (auf echter Hardware!) auch auf Exoten am Laufen halten, weil sie argumentieren, daß so Grenzfälle und Probleme oft leichter gefunden werden, bevor sie einem richtig schmerzhaft auf die Füße fallen.

          [
          | Versenden | Drucken ]
          • 0
            Von klopskind am Fr, 14. Juni 2019 um 17:56 #

            Wenn ich wirklich DF will und weiß, [...]
            Ja, dann ist es zweifelsohne geeignet.

            TeX auf FreeBSD [...]
            Es war nur ein Beispiel für kostenlose, breit verfügbare, nachgefragte und zentrale OSS für Unixoide, welche in den FreeBSD (und damit auch den DPorts) derzeit nicht verfügbar ist, geschweige denn rund läuft; von proprietären Produkten gar nicht erst zu sprechen.

            Am Wochenende landet mit „zziplib“ die letzte Laufzeit-Abhängigkeit für TeXLive in Raven, versprochen. Sollte ich mich nicht vertan haben, fehlen dann nur noch zwei weitere Pakete, die ich mir auch mal anschauen will. Vielleicht wird das aus dieser Richtung ja noch was mit TeX...
            Von den Raven-Ports hatten Sie mir schon einmal berichtet. Interessante Sache. Sie verdienen sich meinen Respekt für Ihr Engagement. Bravo und viel Erfolg! :up: :)

            Bei Punkt l stutze ich allerdings. So weit ich weiß, legt DF gerade auf die Performance extrem hohen Wert und macht dabei keine schlechte Figur.
            Korrekt, DF legt großen wert auf Performance und spielt in der Regel bei den "Großen" mit.

            Zahlen und Benchmarks zur Performance hängen allerdings immer vom Workload ab. Verbreitetere Systeme haben hier im Allgemeinen den Vorteil, auf eine möglichst große Anzahl verschiedener Workloads entwickelt, getestet und optimiert zu werden, ohne andere große Abstriche machen zu müssen. Das erhöht natürlich die Systemkomplexität enorm und verbrät viele Entwicklungsressourcen, die DF derzeit fehlen.

            Natürlich kann man viel Tuning betreiben, jedenfalls auf den meisten Systemen. Häufig handelt es sich dabei aber um Tradeoffs. Derzeit ist Linux bspw. im HPC quasi unübertroffen (nicht nur wegen der absoluten Performance, sondern wegen der Möglichkeiten für Tuning und der höheren Energieeffizienz). Die Algorithmen der glibc zur Speichervergabe & -verwaltung sind enorm flexibel und skalierbar, und bieten durch eine Vielzahl an Parametern einen vergleichsweise großen Spielraum für Tuning.
            Ein weiterer Faktor ist, dass kritische Software oftmals auf/für Linux entwickelt, getestet und optimiert und dann erst portiert wird.

            Architekturen
            Ja, das ist mir glatt entfallen, ist aber eigentlich indirekt an Punkt a) gebunden. OpenBSD ist hier wirklich vorbildlich, hat aber in den vergangenen Jahren so einige Architekturen rausgeschmissen.

            [
            | Versenden | Drucken ]
        0
        Von kraileth am Fr, 14. Juni 2019 um 15:36 #

        In meinem Fall vor allem: Hardware. Ich habe keine Maschine, auf der DF richtig liefe (habe es unregelmäßig probiert). Was hast Du denn für einen Laptop, wenn ich fragen darf? Da ich einen Großteil meines Engagements für Open Source inzwischen in die Mitarbeit an Ravenports stecke, wäre eine Testmaschine auf der dauerhaft DF läuft für mich recht nützlich (idealerweise mit Dualboot DF/Linux, wenn ich irgendwann mal den GRUB-Port hinbekommen sollte... :cry: ).

        Als primäres BS kommt es für mich u.a. nicht in Frage, weil ich Vagrant/VirtualBox benötige (hoffentlich irgendwann mal Vagrant/Bhyve, aber das ist ja auch FreeBSD und nicht auf DF verfügbar). Sonst könnte ich vermutlich ganz überwiegend mit DF leben. Ich denke, daß ich auf einige Dinge stoßen dürfte, die ich vermissen würde, aber meist kann man die Dinge ja so, anders oder ganz anders machen. Ist immerhin *nix.

        [
        | Versenden | Drucken ]
      1
      Von klopskind am Fr, 14. Juni 2019 um 10:28 #

      Die mir bekannten Versuche HAMMER(2) zu portieren, sind de-facto fehlgeschlagen oder hatten keine ehrgeizigen Ziele; eine "Portierung" kann sehr verschieden angegangen und umgesetzt werden, es ist kein klar definierter Begriff (möglicherweise abseits einer "vollständigen Portierung").

      In diesem Zusammenhang habe ich ein paar interessante Quellen zusammengetragen (teils Sekundärquellen):
      1. Portierungsbericht von Daniel Lorch (2009); Ziel war es, HAMMER1 auf FUSE zu portieren. Der Bericht enthält diverse Details, wie z.B. problematische Differenzen zwischen den verschiedenen VFS-Schichten in Abschnitt 5.
      2. Kommentare von Matthew Dillon zu Aufwand und Details einer Portierung von HAMMER1 für FreeBSD im Rahmen eines GSoC-Projekts.
      3. Ankündigung einer Portierung von HAMMER2 für OpenBSD als GSoC-Projekt 2015 samt teils technischer teils strategischer Hinweise und Diskussionen.
      4. Ankündigung Tomohiro Kusumis zur Portierung von HAMMER2 auf FreeBSD samt anschließenden Kommentaren und Hinweisen.

      Unabhängig davon ist HAMMER2 noch nicht vollständig fertiggestellt, siehe auch DESIGN und TODO. Die wesentlichen Funktionen sind zwar implementiert, aber für den Produktiveinsatz ist es leider noch nicht geeignet.

      Das soll die außerordentlichen Leistungen Matthew Dillons nicht schmälern. Die Vergangenheit suggeriert, dass sich die Entwicklung/Portierung nicht-trivialer Dateisysteme erfahrungsgemäß als äußerst aufwändig, kompliziert und langwierig erweist - und das in verschiedensten Facetten (insbes. aber nicht ausschließlich): Expertise, Engagement, Organisation & Planung, Ausdauer (z.B. finanziell), juristische Aspekte (neben den üblichen unternehmerischen Aspekten z.B. den der Patente), Wettbewerb. Die involvierten Interessengruppen, die Vermarktung und das Momentum spielen ebenfalls eine große Rolle für das Durchsetzungsvermögen und Erfolgsaussichten eines Dateisystems.

      Bisher waren HAMMER und HAMMER2 stets eine "one-man show". Der "bus factor" liegt bei 1. Das stärkt die strategischen Aussichten im Sinne einer Verbreitung dieser Dateisysteme nicht gerade.
      Daher halte ich es für äußerst unwahrscheinlich, mittelfristig eine ambitionierte Portierung von HAMMER2 für den produktiven Einsatz zu erleben, d.h. in üblichen Zeitmaßstäben von Dateisystemen etwa nicht innerhalb der nächsten ~15 Jahre.

      [
      | Versenden | Drucken ]
      0
      Von Atalanttore am Sa, 15. Juni 2019 um 17:04 #

      Was ist am GEOM-Framework so genial?

      [
      | Versenden | Drucken ]
      • 0
        Von kraileth am So, 16. Juni 2019 um 15:18 #

        Die völlige Flexibilität, Speicher einzuteilen - auf konsistente Weise, ganz überwiegend direkt als Teil des Betriebssystems:

        - Ein Speichermedium partitionieren? Macht eine GEOM-Klasse (gpart). Unter Linux brauche ich dafür fdisk, parted, gdisk oder ähnliches; alle funktionieren etwas oder sogar völlig anders.
        - Volume-Manager? Eine GEOM-Klasse (gvinum - wenn auch durch ZFS überwieged obsolet). Unter Linux? LVM. Wieder ein eigenes Programm, das nach seinen eigenen Regeln funktioniert.
        - Softraid? GEOM-Klasse (z.B. gmirror, graid, usw.). Unter Linux: Mdadm (wieder eine Wissenschaft für sich und ein Werkzeug, zu dem ich niemals irgendwie besonders freundliche Gefühle entwickelt habe, während ich die Einfachheit von gmirror schon geliebt habe, als ich noch ausschließlicher Linux-Nutzer war).
        - Verschlüsselung? Natürlich eine GEOM-Klasse (GELI, GDBM). Linux: LUKS/dm-crypt, wieder ein ganz eiges Design, in das man sich, wenn man es nicht so oft nutzt, jedes Mal wieder einlesen muß.
        - Journaling? Wieder eine GEOM-Klasse (gjournal). Unter Linux? Entweder ein Dateisystem unterstützt Journaling - oder eben nicht. Journaled EXT2? Journaled FAT-32 (!)? Nö. Unter FreeBSD? Absolut kein Ding. Warum auch nicht?
        - Labeling eines beliebigen Gerätes / einer beliebigen Partition / was auch immer? GEOM-Klasse (glabel).

        Concatenation? Striping über verschiedenste Speicher-Provider? Verbinden mit einem Cache-Gerät? Multipath-Anbindung? Verfügbarmachung eines Speicherortes über das Netzwerk (Spielereien wie das Abspielen einer Audio-CD in einem entfernten Rechner)? Die Antwort ist jedesmal : GEOM. Hat man einmal die Grundlagen verstanden, kann man für diese ganzen (und weitere) Felder sehr einfach das GEOM-Framework nutzen.

        Die angesprochene Flexibilität kommt daher, daß GEOM-Klassen beliebig stapelbar sind und man die Reihenfolge prinzipiell frei wählen kann (wobei natürlich nicht alles denkbare in der Praxis immer sinnvoll ist).

        Dies sind einige der Punkte, warum ich in Sachen „Storage” FreeBSD für außerordentlich brauchbar und GEOM für ein überwiegend verkanntes Juwel halte.

        Dieser Beitrag wurde 1 mal editiert. Zuletzt am 17. Jun 2019 um 05:11.
        [
        | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung