News Software Freedom Conservancy: Ubuntu verletzt mit ZFS Linux-Lizenzen

mein Punkt war, das es schneller syncronisiert... wie vermutlich auch zfs oder andere systeme. natuerilch kann das auch jedes andere raid system, zfs sei da aber wohl schneller, aber das ist jetzt auch nur was ich gelesen habe.
Zur Geschiwindigkeit kann ich net viel sagen, ich hatte das nur mal getestet bei mir und da war die Geschwindigkeit halt in etwa so schnell wie die einer einzelnen Platte, auf eben die ja kopiert wurde. Die HDD ist letztendlich so oder so der Flaschenhals.

Gerade festplatten kauf ich ungern haufenweise und meist in jahren abstand und in unterschiedlichen groessen.
Naja dann mehrere ungleiche Platten waren schon immer für Raid nicht wirklich praktisch, wird auch imo immer so bleiben.
Was man mit unterschiedlichen Platten machen könnte wäre ein Pool zu erstellen aus mehreren unterschiedliche großen Platten und dann copies auf 2 setzen. Dann wird jeder Block auf 2 unterschiedlichen Platten gespeichert. Man "verliert" dann aber prinzip bedingt 50% an Platz. Oder man kauft HDDs zumindest paarweise in der gleichen größe immer und arbeitet mit mirror.

naja da waeren wir bei den snapshots theoretisch klingt das nice aber die faelle wo ich denke das waere jetzt aber super toll wenn ichs jetzt haette, ergeben sich fuer mich noch nicht.
Ich find es schon ganz praktisch. Habe jeden Tag ein Snapshot und kann dann halt zurückgehen wenn ich etwas suche was ich gelöscht habe. Muss man aber selber wissen ob man das will oder nicht. Mit ZFS kannste es ja einschalten, läuft eh im Hintergrund und stören tut es auch weiter nicht.
 
Ilsan schrieb:
Naja dann mehrere ungleiche Platten waren schon immer für Raid nicht wirklich praktisch, wird auch imo immer so bleiben.
Was man mit unterschiedlichen Platten machen könnte wäre ein Pool zu erstellen aus mehreren unterschiedliche großen Platten und dann copies auf 2 setzen.
k das klingt schon nicht voellig dumm, wenn ich wieder mehr platten haben sollte, bbin aber von 3.5" auf 2.5" um gestiegen und da die festplattenpreise sich nie mehr von den ueberschwemmungen damals erholt haben, bin ich trotzdem recht zurueckhaltend mit kaeufen. hab halt daher in meinem fileserver/htpc nur 2 stueck und die groessere ist halt fuer backup. und 2 verschiedene filesysteme fuer backup explizit nicht btrfs.

sicher ein feuerfester save oder ein getrenntes laufwerk waere sicher noch sichereres backup, aber solange nicht grad der blitz direkt in den computer ein schlaegt und er weg schmiltzt oder die ganze bude abfackelt reicht das fuer mich.

wobei die wichtigsten daten dann eh auf nem anderen rechner sind wie dem wo das backup ist.

Ich find es schon ganz praktisch. Habe jeden Tag ein Snapshot und kann dann halt zurückgehen wenn ich etwas suche was ich gelöscht habe. Muss man aber selber wissen ob man das will oder nicht. Mit ZFS kannste es ja einschalten, läuft eh im Hintergrund und stören tut es auch weiter nicht.

hab jede nacht nen bbackup ueber rsnapshot... der macht auch halt nur die aenderungen den rest macht er halt hard links... also quasi aehnlich.

wo ich bei rsnapshot artigen filebasierten loesungen den nachteil sehe, ist das wuerde ich jetzt mal aus testzwecken ein anderes linux booten und der ssh key wuerde sich nicht aendern fuer den backupserver sprich er haette noch zugriff, wuerde er nicht kapieren das das nen anderes volume ist, er wuerde dann stur z.b. das neue home mit dem alten diffen. dann haettest 2 fette transitions im backup die so gar nicht wirklich real passiert sind :)

dafuer sind die systeme stabil und ausgereift und recht simpel btrfs backup scripts sind eher rum gepfusche im moment, da wuensch ich mir erstmal ein modul fuer rbackup oder wegen mir auch ein fertiges btrfs-backup das mit btrfs send und receive arbeitet dann.

klar ein snapshot geht auch schneller, lokal ohne backup zumindest.
 
Zuletzt bearbeitet:
mambokurt schrieb:
Doch wissen wir, weil die einen Anwälte davon ausgehen dass die Lizenzen nicht vereinbar sind, damit dürfte man ZFS nicht mit dem Kernel bundeln.

Das ist irgendwo, als käme hier als Meldung dass ZFS mit dem Kernel gebundelt wird und du erstmal nachfragst, wie das denn nun im Detail im Code aussieht und warum das nicht mit im Artikel steht. Kann man machen, bringt aber nicht viel ;)

Irgendwie hast du das nicht verstanden das ich halt gerne wissen möchte inwiefern es hier ein Problem gibt und nicht nur das es eins geben soll.

Einfach nur die News nachplappern kann ich auch.

Das kann ich eigentlich nicht so schwer sein.
 
fethomm schrieb:
Dem Einsatz des FS steht nichts im Wege, der Anwender trägt kein praktisches Risiko.

Die Aussage finde ich ein bisschen heikel und würde ich so nicht aussprechen. Wenn man das FS jetzt long-term einsetzen möchte, und mit ZFS formatiert... Dann gibt es ein Rechtsstreit, und Canonical muss ZFS wieder entfernen. Dann steht man mit einem Filesystem mit Terabyte an Daten dar und es gibt keine Bugfixes und Security Updates mehr dazu. Worst-case, aber nicht mal so unwahrscheinlich denk ich mal.
 
Dann steht man mit einem Filesystem mit Terabyte an Daten dar und es gibt keine Bugfixes und Security Updates mehr dazu. Worst-case, aber nicht mal so unwahrscheinlich denk ich mal.
Naja kannst den Pool dann immer noch mounten unter OpenSolaris, FreeBSD. Oder machst dir ZFS on Linux drauf. Weiterbenutzen kannst du ihn dann also schon.
 
tek9 schrieb:
Irgendwie hast du das nicht verstanden das ich halt gerne wissen möchte inwiefern es hier ein Problem gibt und nicht nur das es eins geben soll.

Das 'Problem' ist, dass die Lizenzen _angeblich_ inkompatibel sind. Wenn du genauer wissen möchtest wo es hakt, steht dir frei dem Link im Artikel zu folgen https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/ , da stehts haarklein drin.

Und chithanh hatte das schon ganz richtig erklärt, wenn du also weitere Fragen hast wäre es vielleicht nicht schlecht die mal genauer auszuformulieren statt zu schreiben 'Das versteh ich nicht, wo ist das Problem?'.
Was genau an 'Die Lizenzen sind inkompatibel' verstehst du denn nicht?
Die eine sagt 'das darfst du nur weitergeben wenn X', die andere schließt X explizit aus -> inkompatibel -> Bundle von ZFS und Kernel nicht möglich.
Das ist doch keine Raketenwissenschaft :D
 
Ilsan schrieb:
Naja kannst den Pool dann immer noch mounten unter OpenSolaris, FreeBSD. Oder machst dir ZFS on Linux drauf. Weiterbenutzen kannst du ihn dann also schon.

Naja, ich weiss nicht ob das so einfach ist ...

Open-ZFS = FreeBSD ZFS = ZoL ?

ZFS v5000 (FreeBSD 10.2 & current = 11) hat halt noch andere Funktionen die man unter Umständen nicht benutzen kann.

Mounten ja, aber mit vorbehalt ...

Wenn man eh nur Daten verwalten möchte, kann man ja gleich ein extra NAS od. NAS ähnlichen Rechner haben zur Datenvervaltung mit UNIX,BSD mit ZFS Werkzeugen (GUI's) für die Spapshots des Dateisystems.

PC-BSD hat so etwas und illumos / OpenIndiana glaub ich, Illumos ist aber schwer zu handhaben ...
https://en.wikipedia.org/wiki/OpenZFS
https://en.wikipedia.org/wiki/Illumos
https://en.wikipedia.org/wiki/OpenIndiana
https://www.youtube.com/watch?v=RxNdTurXnYQ
 
Es gibt doch nur noch OpenZFS aka ZFS v5000.
Bei ZFS v28 gabs halt die Aufsplittung weil Oracle den Code nicht mehr veröffentlicht hat. FreeBSD, ZoL, und OpenIndiana usw die benutzen alle dasselbe ZFS. Man kann nur nich mehr zurück zum aktuellen Solaris und umgekehrt.

Bei ZFS würde ich aber einen reinen Storage Server/NAS vorschlagen mit OmniOS und zusätzliche Dienste dann virtualisieren. So kann man auch den integrierten SMB Server nutzen und muss sich nicht mit Samba herumschlagen.

Für OmniOS spricht dass es ne Fork von OpenIndiana ist und ZFS da quasi "zuhause" ist. Sprich dort hat man idr die beste Performance.
 
Ilsan schrieb:
Es gibt doch nur noch OpenZFS aka ZFS v5000.
Bei ZFS v28 gabs halt die Aufsplittung weil Oracle den Code nicht mehr veröffentlicht hat. FreeBSD, ZoL, und OpenIndiana usw die benutzen alle dasselbe ZFS. Man kann nur nich mehr zurück zum aktuellen Solaris und umgekehrt.

Soweit AllanJude mal sagte, ist FreeBSD-current weit voran an ZFS Funktionen, die andere BSD's nicht haben.
Sogar Openindiana / Illumos sind etwas zurück und sollten sich OpenZFS anschliessen.

Dieses v5000 & v28 sind die Tools für ZFS mit den Versionsnummern.

Da ich mich schon länger nicht mit FreeBSD befasst habe, ist das aus dem Gedächtnis mit Vorbehalt.

ZFS(8)-Manpage-FreeBSD-current

Es müsste sicher einen Artikel zu finden sein, wo die Unterschiede von UNIX & BSD-current zu finden sind.
Ein deutsches Forum gibt es ja auch noch ...
http://www.bsdforen.de/
http://wiki.bsdforen.de/howto:zfs
 
v5000 und v28 bezeichnet keine tools. das sind die Versionsnummer von ZFS.
v28 ist wichtig weil das die letzte Version ist die noch kompatibel zu Solaris ist. Oracle ist bei Solaris mittlerweile bei v31 oder v32 meine ich.

Für openzfs war v28 die Ausgangsbasis, danach hat man es um sogenannte "Feature Flags" erweitert. v5000 ist also aktuell.

Dass Openindiana und Illumos groß hinterher sind glaube ich weniger da ZFS daher quasi kommt. Auf FreeBSD wurde es doch auch nur portiert.
Ich benutze OmniOS, da gibts das aktuelle ZFS (v5000) und auch den integrierten SMB Server der ACL beherrscht usw.
Den SMB Server hat FreeBSD beispielsweise nicht sodass man hier auf Samba zurückgreifen kann, was letztendlich nicht ganz so viel kann.
 
Zuletzt bearbeitet:
konkretor schrieb:
Eine Artikel Serie über Linux Dateisysteme fände ich interessant und auch die gröbsten Kommandos wären sicherlich für den Einstieg auch ganz gut.



etwas Offtopic als damals Oracle SUN gekauft hatte war das für die OpenSource Welt schon ein sehr harter Schlag, man sieht es ja auch an den ganzen Forks die daraus entstanden sind....

Wäre wirklich schön dazu mal einen Artikel zu sehen. ;)
 
ZFS und non-ECC RAM:

Will ZFS and non-ECC RAM kill your data? http://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/


Matthew Ahrens schrieb:
There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem. If you use UFS, EXT, NTFS, btrfs, etc without ECC RAM, you are just as much at risk as if you used ZFS without ECC RAM. Actually, ZFS can mitigate this risk to some degree if you enable the unsupported ZFS_DEBUG_MODIFY flag (zfs_flags=0x10). This will checksum the data while at rest in memory, and verify it before writing to disk, thus reducing the window of vulnerability from a memory error.

I would simply say: if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data, such as ZFS.

http://arstechnica.com/civis/viewtopic.php?f=2&t=1235679&p=26303271#p26303271
 
Und wieder einmal stehen Copyrights der Innovation im Weg und die GPL und FSF wird mehr und mehr zu einem Problem statt einer Lösung.
 
Wobei die Lösung ganz einfach ist:


Tl;dr:


bedingungsloses Grundeinkommen, Abschaffung des Copyrights

dann kann jeder entwickeln und erfinden, wie er lustig ist und muss keine Sorgen haben, dass er/sie deswegen am Hungertuch nagt :evillol:
 
Warte, ich bekomme die relative Inkompatibilität von FreeBSD plus alles was Ubuntu schlecht macht in einem Projekt auf Source Forge gehostet mit einer winzigen Community? Sign me in! /irony

Ich kann mich noch an Zeiten erinnern da hatte ich Zeit für solche Späße, aber inzwischen knall ich mir lieber eine generische Linuxdistro auf den Rechner und lasse solche Experimente einfach bleiben, a) liest sich das wie die klassische Eintagsfliege und b) viel Spaß wenn du mal ein Problem hast.... O.o
 
Zurück
Oben