Dateisysteme und gerade solch komplexe wie ZFS benötigen eine tiefe Integration in den Kernel und brauchbare Userland Integration. Wie soll da eine gemeinsame Basis helfen?
Die Linuxdistributoren werden schon dafür "sorgen", dass sich ZFS unter Linux nicht durchsetzt.
Denn das letzte, was diese gebrauchen können, sind Lizenzierungsprobleme beim Ausliefern der Distribution.
Das bedeutet aber auch, dass auf der originalen Distribution ZFS bei den Formatierungs- bzw. Installationsoptionen nicht zur Verfügung stehen kann. Damit ist IMO die ganze Sache bereits "gegessen".
Suse z.B. wird vermutlich komplett auf Btrfs - die Linuxalternative zu ZFS - als Standarddateisystem umschwenken.
>Das bedeutet aber auch, dass auf der originalen Distribution ZFS >bei den Formatierungs- bzw. Installationsoptionen nicht zur >Verfügung stehen kann.
Das betrifft dann zwar den Heimanwender Markt, im Geschäftsumfeld hingegen wo x Systeme eine identische Basis haben (egal ob Client oder Server), spielt der standard Installer eine eher untergeordnete Rolle.
Dass eine grosse Distribution darauf schwenkt bezweifle ich auch, allerdings sitzen einige Hauptentwickler von ZFS on Linux auch beim Lawrence Livermore National Laboratory wo ZFS auf ihren Clustern verwendet. - Anwendungen gibt es und deswegen hat ZFS o. Linux auch in letzter Zeit einiges vorwärts gemacht. Lizenzschwierigkeiten hin oder her
OpenZFS ist - soweit ich das beobachte - mehr eine Ankündigung über eine de-fakto Situation die seit dem Ende der offenen Solaris und ZFS-Entwicklung zementiert wurde und mehr um gegen aussen das auch zu kommunizieren: a) ZFS gibts in 2 Varianten, mit OpenZFS distanziert man sich nun auch von Namen her vom geschlossenen ZFS von Oracle b) OpenZFS soll nicht nur ein Ding für illumos sein, sondern will sich auch klar als FS für andere Plattformen sein.
So wie ich lese ist OpenZFS ist vorwiegend ein Projekt für den Inter-Plattform-Austausch für die OpenZFS Weiterentwicklung und die Kompatibilität zwischen den verschiedenen Portierungen. Nun wird auch klar, dass man sich für OpenZFS interessieren kann, ohne unbedingt tief in den illumos-Code zu gehen. Manche Institutionen und Firmen wollen das Filesystem, sind ansonsten aber auf Linux (LNLL) oder BSD (ixSystems etwa) ausgerichtet.
sehe da nicht so sehr das Problem, wenn das System selbst mit einem anderem Filesystem läuft und zfs nur für die Daten verwendet wird.
Als Normalanwender profitiert man auch kaum von zfs, viele Features kann man auch wegen des Speicherbedarfs gar nicht nutzen. Das wichtigste, sind Tools um Daten wieder herstellen zu können, wenn etwas schief geht. Bei den klassischen Systemen ist der Wekrzeugkasten gut gefüllt. Bei den ganzen modernen Filesystemen sind zum Teil die Tools nicht vorhanden oder nicht ausgereift. Umso wichtiger wird das bei pravatanwendern nie vorhandene Backup.
Im Serverumfeld lohnt sich zfs, für den Normalanwender sehe ich keinen echten Bedarf.
Von M wie Meikel am Fr, 20. September 2013 um 01:14 #
> Als Normalanwender profitiert man auch kaum von zfs, viele Features kann man auch wegen des Speicherbedarfs gar nicht nutzen.
Welche Features?
> Das wichtigste, sind Tools um Daten wieder herstellen zu können, wenn etwas schief geht.
Welche Tools fehlen dir bei ZFS?
Wenn man natürlich stur am klassischen Unix-Konzept hängt, ist ZFS erst einmal gewöhnungsbedürftig. Mehrere Filesysteme in einem Pool? Volume-Manager integriert? Online-Fsck? Aber das legt sich mit der Zeit.
Das sind doch nur Allgemeinplätze. Ich setze ZFS on Linux jetzt schon seit 1 Jahr auf mehren Servern ein und bin begeistert . Absolut zuverlässsig. Über die Funktionalität brauchen wir nicht reden und die Userlandtools sind vom Feinsten. Aber warum sollte man ein Modul nicht tief den Kernel integrieren können?
Ich setze es nicht auf einen, sondern zumindest auf vier Servern ein, die insgesamt 40 Virtuelle Maschinen beherbergen. Natürlich ist das nicht riesig, aber immerhin. Mit Shapshoots und ZVOL's sind Backups und Migrationen einfach ein Traum.
Die Problematik ist, was man erreichen will. Soll es solides FS sein, ist eine tiefe integration in den Kernel von Nutzen. Dann benötigt es aber für jedes System Illuminos, BSD und Linux jeweils eigenen Code. Dann müssen sich die Entwicklungen untereinander abgestimmten Standards orientieren. Das ist zwar machbar aber sehr aufwendig.
Will man ein portables System auf einer einheitlichen Codebasis um Entwicklungsaufwand zu verkürzen dürfen die Module sich nicht zu sehr mit dem Kernel verzahnen.
Schließlich gibt es noch die unterschiedlichen Lizenzen.
Dateisysteme und gerade solch komplexe wie ZFS benötigen eine tiefe Integration in den Kernel und brauchbare Userland Integration. Wie soll da eine gemeinsame Basis helfen?
Kann man nicht den CDDL-Code in ein Kernel-Modul auslagern, das nicht mit dem Kernel ausgeliefert wird sondern nachinstalliert werden muss?
Falls das eine Frage war, steht die Antwort bereits im Text:
Nur wenig.
Die Linuxdistributoren werden schon dafür "sorgen", dass sich ZFS unter Linux nicht durchsetzt.
Denn das letzte, was diese gebrauchen können, sind Lizenzierungsprobleme beim Ausliefern der Distribution.
Das bedeutet aber auch, dass auf der originalen Distribution ZFS bei den Formatierungs- bzw. Installationsoptionen nicht zur Verfügung stehen kann. Damit ist IMO die ganze Sache bereits "gegessen".
Suse z.B. wird vermutlich komplett auf Btrfs - die Linuxalternative zu ZFS - als Standarddateisystem umschwenken.
>Das bedeutet aber auch, dass auf der originalen Distribution ZFS
>bei den Formatierungs- bzw. Installationsoptionen nicht zur
>Verfügung stehen kann.
Das betrifft dann zwar den Heimanwender Markt, im Geschäftsumfeld hingegen wo x Systeme eine identische Basis haben (egal ob Client oder Server), spielt der standard Installer eine eher untergeordnete Rolle.
Dass eine grosse Distribution darauf schwenkt bezweifle ich auch, allerdings sitzen einige Hauptentwickler von ZFS on Linux auch beim Lawrence Livermore National Laboratory wo ZFS auf ihren Clustern verwendet. - Anwendungen gibt es und deswegen hat ZFS o. Linux auch in letzter Zeit einiges vorwärts gemacht. Lizenzschwierigkeiten hin oder her
OpenZFS ist - soweit ich das beobachte - mehr eine Ankündigung über eine de-fakto Situation die seit dem Ende der offenen Solaris und ZFS-Entwicklung zementiert wurde und mehr um gegen aussen das auch zu kommunizieren:
a) ZFS gibts in 2 Varianten, mit OpenZFS distanziert man sich nun auch von Namen her vom geschlossenen ZFS von Oracle
b) OpenZFS soll nicht nur ein Ding für illumos sein, sondern will sich auch klar als FS für andere Plattformen sein.
So wie ich lese ist OpenZFS ist vorwiegend ein Projekt für den Inter-Plattform-Austausch für die OpenZFS Weiterentwicklung und die Kompatibilität zwischen den verschiedenen Portierungen. Nun wird auch klar, dass man sich für OpenZFS interessieren kann, ohne unbedingt tief in den illumos-Code zu gehen. Manche Institutionen und Firmen wollen das Filesystem, sind ansonsten aber auf Linux (LNLL) oder BSD (ixSystems etwa) ausgerichtet.
sehe da nicht so sehr das Problem, wenn das System selbst mit einem anderem Filesystem läuft und zfs nur für die Daten verwendet wird.
Als Normalanwender profitiert man auch kaum von zfs, viele Features kann man auch wegen des Speicherbedarfs gar nicht nutzen. Das wichtigste, sind Tools um Daten wieder herstellen zu können, wenn etwas schief geht. Bei den klassischen Systemen ist der Wekrzeugkasten gut gefüllt. Bei den ganzen modernen Filesystemen sind zum Teil die Tools nicht vorhanden oder nicht ausgereift. Umso wichtiger wird das bei pravatanwendern nie vorhandene Backup.
Im Serverumfeld lohnt sich zfs, für den Normalanwender sehe ich keinen echten Bedarf.
> Als Normalanwender profitiert man auch kaum von zfs, viele Features kann man auch wegen des Speicherbedarfs gar nicht nutzen.
Welche Features?
> Das wichtigste, sind Tools um Daten wieder herstellen zu können, wenn etwas schief geht.
Welche Tools fehlen dir bei ZFS?
Wenn man natürlich stur am klassischen Unix-Konzept hängt, ist ZFS erst einmal gewöhnungsbedürftig. Mehrere Filesysteme in einem Pool? Volume-Manager integriert? Online-Fsck? Aber das legt sich mit der Zeit.
Das sind doch nur Allgemeinplätze.
Ich setze ZFS on Linux jetzt schon seit 1 Jahr auf mehren Servern ein und bin begeistert .
Absolut zuverlässsig.
Über die Funktionalität brauchen wir nicht reden und die Userlandtools sind vom Feinsten.
Aber warum sollte man ein Modul nicht tief den Kernel integrieren können?
Ein Jahr und du willst von zuverlaessig reden..bei einem server???? Wenn du 100 hast und nix passiert in einem Jahr...das ist stabil.
Ich setze es nicht auf einen, sondern zumindest auf vier Servern ein,
die insgesamt 40 Virtuelle Maschinen beherbergen.
Natürlich ist das nicht riesig, aber immerhin.
Mit Shapshoots und ZVOL's sind Backups und Migrationen einfach ein Traum.
Klingt interessant, welches Host-OS und welche Virtualisierung setzt du ein?
Als Virtualisierung setzte ich qemu mit libvirt ein.
VM`s sind gemischt, win2008 und linux.
Ausserdem ist spice im Einsatz.
Ich habe auf den Servern noch Archlinux, das ist historisch begründet und nicht so sehr zu empfehlen.
Das Betriebsystem liegt auf einer ext4-Partition,sonst könnte ich kein Rescue booten.
Die ZFS-Pools werden als Mirror mit jeweils 2 Platten betrieben.
Die Problematik ist, was man erreichen will. Soll es solides FS sein, ist eine tiefe integration in den Kernel von Nutzen. Dann benötigt es aber für jedes System Illuminos, BSD und Linux jeweils eigenen Code. Dann müssen sich die Entwicklungen untereinander abgestimmten Standards orientieren. Das ist zwar machbar aber sehr aufwendig.
Will man ein portables System auf einer einheitlichen Codebasis um Entwicklungsaufwand zu verkürzen dürfen die Module sich nicht zu sehr mit dem Kernel verzahnen.
Schließlich gibt es noch die unterschiedlichen Lizenzen.
So ein Quatsch!
Schon mal was von modularer Softwareentwicklung gehört.