21.1 Und immer noch keine ZFS root Installation

[nti]

Warum nur nicht? Für mich DER Grund bei PFSense zu bleiben....

[chemlud]

Klär mich auf, was entgeht mir da?

[franco]

Ich kann dich ja verstehen und bin auch selbst daran schuld in 2020 nicht dafür geackert zu haben, aber dennoch möchte ich sagen: lass das mal lieber mit OPNsense.  :)


Grüsse
Franco

[lfirewall1243]

Warum nur nicht? Für mich DER Grund bei PFSense zu bleiben....

Was wären die Vorteile? Vorallem müssen die Vorteile ja so stark sein, dass man die Entscheidung eines Firewall Systems davon Abhängig macht (wo der Fokus ja eigentlich auf etwas anderem liegt als auf ZFS)  ;D

[msi]

Bin zwar nur ein bis vor kurzem aussenstehender (nicht-registrierter) Mitleser und deshalb ist meine Stimme nich sooo relevant.  :P

Als Kontext: Bei mir kein absolut zwingender Grund (das "gute alte" UFS ist auch solid), aber mit ZFS kann ich zumindest Updates entspannter angehen lassen. Seit FreeBSD selber 'bectl' von Haus aus mitbringt, kann ich ohne jegliche Zusatzpakete (beadm) ein boot environment machen, lasse das Update durchlaufen und wenn es Problem gibt, boote ich halt ins alte BE zurück. Ausser der Zeit fürs rebooten weiss ich, dass ich ohne Schmerzen auf einen "known good" Zustand zurückkehren kann.

Eine Frage an Franco: Wäre das das relevante repository? https://github.com/opnsense/installer/

Zeit habe ich auch nicht im Überfluss, aber einen Blick werfen, was fehlt, sollte ich noch schaffen, vielleicht reichts einmal für 1-2 Zeilen Patches, wer weiss...  :)

[mimugmail]

Guck mal die Issues bei pfsense bzgl. zfs an. Dafür ist das Projekt eigentlich noch nicht groß genug.
Das Problem ist ja dass 99,9% mit dem Vorteil nichts anfangen können und die 0,1% wahrscheinlich 25% mehr Support Issues deswegen verursachen.

Nur meine persönliche Meinung.

[AlienMindbender]

Kann mich da nur anschließen. ZFS für Storage, z.B. TrueNAS? Sowieso.
Für eine Firewall? Da sehe ich andere Prioritäten.

[JeGr]

> Guck mal die Issues bei pfsense bzgl. zfs an. Dafür ist das Projekt eigentlich noch nicht groß genug.

Blöde Frage aber welche Issues? Die meisten Issues die bei uns als Support aufschlagen sind genau wegen UFS weil die Leute die Kisten behandeln wie 0815 Router. Ausgeschaltet ohne runterfahren, nicht an USV angehängt etc. etc. Und dann gibts File System Corruptions. Hatten wir mehrfach. Seit wir die Kunden mit pfSense nur noch mit ZFS ausliefern (default ZFS Install genügt vollkommen) hatten wir mit den Boxen auch bei solchen Kunden mit Stromausfall, hartem Reboot etc. keinerlei Probleme mehr mit FS Corruption etc.

Also ich verstehe dass man den Fokus da aus Developer Sicht nicht drauf legt, aber diese 2000er Aussage bzw. die Kommentare die das so mit "ZFS nur Storage blubb" abbügeln, kann ich daher absolut nicht nachvollziehen, sorry. :)

Uns hat es gerade FS bezogene Probleme wesentlich reduziert und daher finde ich es ebenfalls schade, dass es leider bislang keine Installer Unterstützung für Setup mit ZFS gibt. Vor allem weil sich das - eingeschleift in den Updater mit "Rollback" bei fehlgeschlagenem Update / Switch auf vorhandenes BE/alte Version absolut anbieten würde.

[AlienMindbender]

Ein Stromausfall ist aber bei anderen gängigen Journaling-FS (NTFS, ext3/4...) auch kein Problem. Wenn UFS da Probleme macht wäre es doch einfacher auch gjournal zu verwenden...?

[JeGr]

Naja "was anderes" zu benutzen ist eben genau der Punkt ;)
Und ob es nun UFS+gjournal ist (Interessensfrage: warum war das eigentlich nie ein Punkt das generell mit ins Spiel zu bringen?) oder ob es ZFS ist, was bei den Filesystem Größen die wir bei OPNsense normalerweise sehen (also ~2-3GB in use) keinen großen Overhead produziert und einfach eben gerade durch den Einsatz im NAS/SAN Bereich solide ist, wäre an der Stelle ja recht egal.
Nur kann man dann eben - wenn man sich ZFS ran nimmt - auch die ganzen anderen Features mit unter den Nagel reißen und eben Snapshotting, Redundanz auf Blocklevel etc. reinbringen. Denn wenn ich ne Kiste habe, die ~2-3GB braucht - lassen wirs 10GB mit großen Logs sein - und ich habe ne 64GB SSD verbaut (meist bekommt man heute eh kaum noch kleinere Sachen als 128/256 wenns ordentliche Qualität ist), dann ist mir recht egal, ob ein File in 1KB ggf. 2KB braucht weil seine Blöcke redundant 1-2fach redundant auf der SSD verteilt werden. Und genug Platz für Snapshots bei einem Update ist dann auch, womit ich eine schöne Rollback Möglichkeit habe. Oder für Spezialkisten mit CF oder SD Karten oder auch USB Sticks als Bootmedium auch problemlos RAID-1 auf 2-n Geräten.

Mein Punkt ist einfach: wir haben in BSD mit ZFS ein rock solid enterprise grade Filesystem. Dass das für Storage super/gedacht ist - ja klar. Aber das macht es doch nicht automatisch schlecht für den Einsatzzweck einer Firewall/Security Appliance, die noch dazu (in den meisten Fällen) keine großen Anforderungen an IOPS oder Perfomance hat. Von Live Deduplication oder sonstwas redet ja niemand ;) Aber warum soll man die ganzen sinnvollen Features wie blocklevel redundancy, snapshotting und multi boot environments liegen lassen, nur weil es "hauptsächlich" auf Storage fokussiert ist? Und nachgewiesenermaßen es immer mal wieder mit UFS rummst gerade wenn es hard resets oder power losses sind?

Und nein, das ist kein Meckerpost à la "das muss jetzt implementiert werden, warum macht ihr das nicht", aber ich verstehe da gerade die vielen Stimmen dagegen nicht, die alle rufen "das ist ein Storage Ding, das braucht keiner". Warum denn nicht? Und wie gesagt, wir haben da nach mehr als 3 Jahren in der pfSense Ecke nur gute Erfahrungen gemacht. Auch wenn wir genauso am Anfang die Leute bei der Installation überzeugen mussten es auszuprobieren weil "warum soll ich da so ein Storage Ding draufinstallieren" war tatsächlich anfänglich eine Dauerbrennerfrage ;) Inzwischen allerdings kaum noch :)

[Gauss23]

kein Meckerpost à la "das muss jetzt implementiert werden, warum macht ihr das nicht", aber

+1

Wie groß ist der Aufwand das zu implementieren? Da muss der Installer sicherlich umgebaut werden. Kann man ja ggf. optional machen.

Dann könnte man vor jedem Update ein Snapshot erstellen lassen und es bräuchte vermutlich noch ein Interface, um einen Rollback machen zu können.

Nachtrag: eben https://github.com/opnsense/installer gefunden. Ob der mal den jetzigen Installer ablösen soll?

In https://github.com/opnsense/installer/blob/master/scripts/opnsense.sh sind die relevanten ZFS Teile auskommentiert. Benutzt wird offenbar noch die "alte" Version vom Installer: https://github.com/opnsense/bsdinstaller
In dem Repo findet sich das Wort ZFS an 4 Stellen.

[AlienMindbender]

Mein Punkt ist einfach: wir haben in BSD mit ZFS ein rock solid enterprise grade Filesystem.

Das stimmt sicher, nur wird "rock solid" aus der BSD-Ecke (FreeNAS / TrueNAS) immer wieder an Bedingungen geknüpft:

• 2 GB RAM seien die Untergrenze für ZFS, ohne irgendwelche Services,
• eine USV gehöre zur Standardausstattung,
• und wer kein ECC einsetzt möge sich  überhaupt gleich teufelchenrot verkriechen, da seien Probleme vorprogrammiert

Das ist vielleicht alles übertrieben, trägt aber zum "Respekt" (Misstrauen) gegenüber ZFS bei. Mir ist noch kein Kommentar untergekommen der ECC für ext4, NTFS oder FAT fordert.
(Was im Umkehrschluss aber natürlich nicht heißt dass ich FAT gegenüber ZFS bevorzugen würde  ;D)

[Patrick M. Hausen]

Dieses "Wissen" ist aber längst widerlegt, schlimm genug, dass es immer noch wiederholt und wiederholt wird ...

ZFS ohne ECC ist immer noch zuverlässiger als jedes andere Dateisystem ohne ECC. Der "Scrub of Death" ist ein Mythos. Und 2 GB RAM mit Anwendungen ist auch völlig ausreichend. Es ist ja nicht so, dass OPNsense eine Storage Appliance wäre.  ;)

https://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/

[AlienMindbender]

Der Einsatz von ECC bei ZFS wird aber nach wie vor promotet, z.B. auch in der offiziellen TrueNAS Doku:

Using ECC RAM is strongly recommended

(Quelle: https://www.truenas.com/docs/hub/intro/corehardwareguide/)

Das heißt aber natürlich nicht, dass andere Dateisysteme ohne ECC sicherer wären. Einen Vergleich dazu habe ich noch nirgends gesehen. Gut möglich, dass ZFS in der Tat auch mit und ohne ECC am stabilsten ist (und man halt das "Pech" hat als einziger ECC zu empfehlen)...  :)

[Patrick M. Hausen]

Natürlich. ECC ist immer sinnvoll. Und jeder vernünftige Rechner hatte das vor 30 Jahren. Intel ist schuld an der "bei einem Desktop braucht man das doch nicht ..." Idee. Und der Marktseparation. Teure Hardwar für Server, billige für "Consumer". Statt dass die teure durch die Stückzahlen billiger wird. Es hätte niemals ein IDE oder ein SATA geben dürfen, es gibt keinen technischen Grund für deren Existenz. SCSI und später SAS in Stückzahlen raushauen und billiger machen wäre sinnvoll gewesen. Genau so mit ECC.