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

Was bedeutet es für die Anwender, wenn Canonnical eine Rechtstreit dazu verliert? Ist es ein Risiko, das FS einzusetzen?
 
Wieso soll es ein Risiko für den Endbenutzer sein ZFS einzusetzen ?

Der kann zu Hause tun und lassen, was er will,


wenn einige Stimmen sagen es ist in Ordnung, andere - dass es nicht in Ordnung ist; ja was stimmt nun ?

Was soll einen davon abhalten ?
 
Mr.Seymour Buds schrieb:
Wie "bedient" man den ext4? Bin kein Spezialist für Dateisysteme. Da würde ich mir wirklich mal einen tiefergehenden Artikel wünschen....Gerade bei Linux hat man ja mehr Auswahl, als zB Windows mit "nur" NTFS...
Wie jedes FS: mit den gewünschten Parametern erstellt man das FS, dann mountet man es (oder permanent in die fstab), befüllt mit den gewünschten Daten usw.

blackiwid schrieb:
Hatte glaub bei nem umzug mein fedora auf ne btrfs platte kopiert und zum laufen gebracht. es macht fuer mich keinen sinn eine btrfs partition an zu legen oder lvm zu benutzen um zu partitionen wenn btrfs das alles im grunde selber kann. daher hab ich direkt /dev/sda mit btrfs formatiert.

wenn ich manuell grub-install drauf laufen lasse laeuft alles wunderbar. Aber irgend ein Muellscript von Redhat crashed oder bricht ab wenn ein neuer kernel als update kommt. und ich muss jedesmal hinterher manuell grub2-mkconfig laufen lassen.
Und was wäre mit einer klassischen Boot-Partition?

Ilsan schrieb:
Das stimmt doch gar nicht. ZFS nutzt den Ram halt als Cache, daher profitiert es eben von viel Ram. Wenn wenig Ram vorhanden ist so fällt der Speed eben auf das Tempo der Platten zurück.
[...]
4GB reichen vollkommen für ZFS, es kommt drauf an was man genau vorhat.Wenn 32GB drin sind werden halt auch 32GB fürs Caching benutzt.
Aber das macht der Kernel doch bei jedem FS, permanent.
Sobald man Daten bewegt, wird der freie RAM als Cache verwendet.

Bruddelsupp schrieb:
Was bedeutet es für die Anwender, wenn Canonnical eine Rechtstreit dazu verliert? Ist es ein Risiko, das FS einzusetzen?
Gar nichts. Du kannst dir den Code auch ziehen und das Kernel Modul in den eigenen Kernel backen, sollte dieses aus Lizenzgründen irgend wann mal wieder raus genommen werden.
 
Aber das macht der Kernel doch bei jedem FS, permanent.
Sobald man Daten bewegt, wird der freie RAM als Cache verwendet.
Es gibt aber keinen Lesecache in der Form. Kopier doch mehrmals hintereinander eine 1GB große Datei irgendwo anders hin. Die wird jedesmal wieder von der Platte neu gelesen.
 
Bruddelsupp schrieb:
Was bedeutet es für die Anwender, wenn Canonnical eine Rechtstreit dazu verliert? Ist es ein Risiko, das FS einzusetzen?
Erst mal müßte es einen Kläger geben...
Dem Einsatz des FS steht nichts im Wege, der Anwender trägt kein praktisches Risiko.
 
cirrussc schrieb:
Und was wäre mit einer klassischen Boot-Partition?
ja dann brauch ich aber wieder partitionen und wollte mir den overhead ersparen, grub selbt kommt ja auch super damit klar aber dieses von geisteskranken Redhat Angestellten tool grubby faengt hier grub ab und wirft einen Fehler obwohl alles perfekt ist. Halt weil Redhat das nicht offiziel supportet. Das grubteam tuts aber. muss nun jeder opensource software entwickler erst redhat fragen ob sie bestimmte features anbieten darf, und wenn nicht dann werden die features von Redhat unterbunden?

Ergibt fuer mich kein Sinn. Aber der Zustaendige Entwickler bekommt wohl Geld dafuer das er trollt. So stellte sich das mal in der Mailingliste fuer mich dar.
 
Ilsan schrieb:
Es gibt aber keinen Lesecache in der Form. Kopier doch mehrmals hintereinander eine 1GB große Datei irgendwo anders hin. Die wird jedesmal wieder von der Platte neu gelesen.

Wo hast du denn das gelesen ?


Nein wird sie nicht, wenn der RAM groß genug ist, landet die Datei komplett im Arbeitsspeicher und wird dann beim 1+X-ten Mal immer vom Arbeitsspeicher zum Zielort kopiert.


Mit der Zeit wird die Datei oder Teile davon natürlich aus dem RAM geschmissen, wenn neue Daten kommen


https://www.thomas-krenn.com/de/wiki/Linux_Page_Cache


bei ZFS ist das so, dass Dateien im ARC gespeichert werden (https://en.wikipedia.org/wiki/Adaptive_replacement_cache),

mit einem L2ARC Laufwerk (SSD) wird ab dem zweiten Lesevorgang die Datei jedesmal von der SSDs gelesen.



Wenn rsync im Einsatz ist kann das bei mehreren GiB oder TiB Daten, die inkrementell aktualisiert werden schonmal Teile des Betriebssystems (Datenbank, GUI, etc.) aus dem RAM kicken, was in der Form evtl. nicht erwünscht ist:

http://insights.oetiker.ch/linux/fadvise/

rsync kann den Kernel anweisen das zu unterlassen, es werden also die Dateien von A nach B kopiert ohne zwischenzuspeichern,


es gibt diverse Mechanismen das ganze wiederum zu beschleunigen, z.B. via splice()
https://en.wikipedia.org/wiki/Splice_(system_call)
 
Vielleicht lassen sich die rechtlichen Probleme ja umgehen, indem man einen Loader, der unter der BSD Lizenz steht, als Kernel Modul einbaut und dieser Lädt dann eine ZFS.so?
 
Ilsan schrieb:
Das stimmt doch gar nicht. ZFS nutzt den Ram halt als Cache, daher profitiert es eben von viel Ram. Wenn wenig Ram vorhanden ist so fällt der Speed eben auf das Tempo der Platten zurück.

Das ist nur die halbe Wahrheit ZFS laeuft mit 128bit das verbrauch/verschwendet massiv Speicher ohne das durchschnittliche Desktopsysteme irgendeinen Mehrwert davon haben.

Mag zum teil auch am seperaten Rammanage-code liegen waerend btrfs den internen vom kernel benutzt. soweit ich zfs und alles verstehe wird sich das auch nicht aendern lassen. Ich kann dir nicht im detail die gruende nennen, es gibt aber 0 artikel darueber das btrfs massiv ram braucht und 1mio das zfs viel ram braucht oder "will". Das ist fakt und hab versucht benchmarks zu finden, mit wenig ram, sah aber nur ein benchmark von 2013 auf phoronix wo mit 8gb ram (was ja viel ist) btrfs zfs zersaeegt hat. Ich wuerde wetten das bei 1-4gb ram die Benchmarks deutlich staerker noch zu gunsten btrfs gehen wuerden.
Und btrfs isst nicht gerade wegen des speeds beruehmt (sondern eher wegen den features) und trotzdem zersaegt es zfs. Mag an der fuse implementierung liegen aber es gibt sehr gute fuse implementierungen mit hohem speed.
Sprich durch mehr Ram kann man ZFS "tunen", aber wirklich brauchen tut man den Ram nicht, es ist dann eben nur nicht ganz so schnell. Sollte aber dann auf dem Niveau von btrfs liegen eigentlich.

"sollte"
"das stimmt doch gar nicht" solltest mit mehr als einem "sollte" belegen. Ich kenne keine seite die empfiehlt ne bestimmte menge von ram zu benutzen fuer btrfs, ich kenne seiten die das aber fuer ZFS tun.

4GB reichen vollkommen für ZFS, es kommt drauf an was man genau vorhat.Wenn 32GB drin sind werden halt auch 32GB fürs Caching benutzt.

4gb reichen hab ich doch gesagt, untere Grenze. darunter sollte man nicht gehen wenn man nicht groessere Schmerzer erleben will.

Und das eben dann nur fuer was kleines, mehrere x tb platten willst da nicht mit managen.

Aber auch btrfs kann kein Ram nutzen, der nicht da ist. Zaubern kann ZFS halt auch nicht;) Dass der Speed leidet ist daher in meinen Augen ne ungünstige Formulierung.

Du kannst mir vielleicht vorwerfen das ich nur halbwissen verbreite, und hier keine beweislinks auf die schnelle finde, das es nicht stimmt kannst du aber genauso wenig belegen. Daher waere ich mit schon fast nem Luegenvorwurf (das stimmt doch gar nicht) vorsichtig.

1. eigener Speicherverwaltung
2. 128bit wortlaenge

koennten die gruende sein warum zfs so ramhungrig ist.

"You need MINIMUM of 1GB of RAM per Terrabyte of storage, on TOP of what is needed for the OS to run."

ich finde lauter solche aussagen, sicher wenn man ssds hat kommt da vielleicht nicht so viel zusammen, aber selbst 1gb exclusiv fuers fs ist schon viel. Der Browser will ja auch immer 1-2 gb ram, wenn dann irgendwas anderess laeuft bist mit 4gb ram schnell am ende.


Sorry aber kannst du mir mal verraten wie du Daten wiederherstellen willst ohne Kopie? Siehst du das als Nachteil jetzt an weil ZFS sich die verlorenen Daten nicht aus den Fingern saugen kann?

das war kein vorwurf im sinne das das gehen soll, das war mir aber vor ich btrfs genutzt habe nicht klar, hab vor dem zfs populaer geworden ist noch nie etwas von bitrod gehoert und auch nicht wirklich das problem verstanden. frag mich auch warum andere raidsysteme das nicht fixen koennen aber das ein anderes thema.

Nun wirbt aber zfs sehr offensiv mit dem thema, nur wird nicht immer dazu geschrieben das dieses feature nur mit raid funtzt, das ist als insider vielleicht klar, aber fuer einen desktop user ist das nicht klar und dann bleibt fuer einen desktopuser oft nicht viel an vorteilen uebrig, er muss aber einige an einarbeitung/maintaining und hardware investieren im zweifel.

Das ist alles was ich sage, das werfe ich niemandem vor ich sage nur wie es ist. Oder moechte zumindest als warnung darauf hin weisen das man sich genau ueberlegen soll ob es einem wirklich mehr vorteile als nachteile bringt.


Ich schätze du würdest den Nobel Preis dafür bekommen wenn du einen Algo erfindest der sowas kann;)

nochmal es sollte einem klar sein, das das feature bei desktop systemen die zu 90% oder mehr kein raid lokal benutzen das feature halt nicht greift das ist alles, ich denke hier sind nicht nur bezahlte Netzwerkadmins die die kommentare lesen, ich bin mit Linux sehr vertraut mehr als die meisten hier und selst mir war das nicht von anfang an klar, das ist in dem sinn auch keine zfs kritik das selbe gilt hier ja auch fuer btrfs.
Obendrein hast du nicht ganz recht. Bei einer HDD kann ZFS dir zumindest sehr wohl anzeigen dass die Daten beschädigt sind. Noch dazu existieren auch bei einer Platte zumindest Kopien der Metadaten welche wieder hergestellt werden können. Wenn du noch mehr willst setze halt copies auf 2. Dann werden auch deine Dokumente 2mal auf der selben Platte abgelegt und können somit auch wiederhergestellt werden. Im Rahmen dessen was physikalisch möglich ist! Informationen aus dem Nichts heraus kannst du nicht wiederherstellen.

Das mag fuer zfs vielleicht einfach gehen, wenn man nicht stunden zeit hat sich mit zu beschaeftigen ist das aber zumindest in btrfs nicht sehr intuitiv, wenns ueberhaupt geht. schon alleine das die anzeige ueber belegung, ist ein witz, es kann sein du hast 30gb dateien auf deinem os aber es sind 80gb belegt, teilweise widersprechen sich die angaben auch. Mag ja auch sinnvoll sein, aber das ist ne umgewoehnug bei ext4 oder xfs schau bei df krieg eine anzeige die stimmt und gut, ich muss mich nicht mit 50 verschieden tools und anzeigen und der komplexen struktur des fs auseinandersetzen und alles ist recht simpel.

Ich kann solche probbleme loesen aber bei vielen Leuten ist halt der Computer "kaputt" wenn X nimmer startet, besonders wenn man nur 50gb daten auf nem 120gb festplatte drauf hat, aber das fs nicht selbststaendig dafuer sorgt das die restlichen 70gb spaetenstens wenn man sie braucht frei macht. und man dem fs mit 1000 befehlen sagen mus das es das doch bitte jetzt tun soll.

Was obendrein ein tolles Feature wäre wenn ich eine große Festplatte verbaut habe aber nur wenig Daten habe zum drauf speichern. So kann ich den Platz dennoch für mich sinnvoll nutzen, weil meine Daten doppelt vorhanden sind und kann die eine Kopie nicht gelesen werden, wird eben die andere Kopie gelesen.

Schoen und gut aber soll leute geben die nicht vollzeit systemadmins sind, die wollen mit ihrem pc arbeiten und nicht staendig das fs managen und beobachten.
 
Zuletzt bearbeitet:
Irgendwie scheint mir das mit diesem ZFS ziemlich abenteuerlich zu sein...

Ich sehe auch irgendwie nicht die Vorteile für Privatpersonen. Dafür so ein tamtam zu machen.

Ich glaube ich würde trotzdem ext4 formatieren auch wenn es dabei ist.

Ich hoffe mal das Ubuntu/Kubuntu 16.04 ein gutes OS wird, hatte eigentlich vor das dann aufzuspielen und Windows großteils zu ersetzen.
 
Euch ist schon bewusst das ZFS für Ubuntu für den Einsatz von Cloudservern sowie Container Virtualisierung und nicht für den Desktop mit liefern will? Somit sind die Argumente um Desktop Einsatz eigentlich nebenläufig, klar wird es ein paar Benutzer geben die es auf Ihrer Desktop Kiste benutzen werden.

Hier ist jedoch dann der User in der Verantwortung sich zu Informieren ob es Ihm Vor oder/und Nachteile bringt.
 
Mr.Seymour Buds schrieb:
Es ging doch im Wesentlichen um Ubuntu Desktop. Was hat das mit NAS und Server zu tun?

Sollte man, gegeben Ubuntu wählt nun ZFS, auf EEC Ram setzen und wenn ja, warum? Fragen über Fragen....

Ne gings nicht. Canonical will grad mehr ins professionelle Umfeld mit Docker & Co, die werden nun aber nicht unbedingt für Server einen eigenen Kernel machen wollen (selbst wenn wärs auch egal).

Ecc ist kann nicht muss, wenn man ein Dateisystem mit 'Selbstheilungskräften' benutzt statt zb ext4 wird man aber einen Grund dafür haben, und dann ist es irgendwo auch logisch Ecc Ram zu nutzen.
 
Ich kenne keine seite die empfiehlt ne bestimmte menge von ram zu benutzen fuer btrfs, ich kenne seiten die das aber fuer ZFS tun.
Nur beziehen sich solche Aussagen von "solchen" Seiten auch oft auf irgendwelche Dinge, da wo irgendjemand mal gehört hat dass ZFS viel Ram benötigt. Komisch ist auch dass oft ne generelle Empfehlung ausgesprochen werden kann. Scheint wohl tatsächlich komplett egal sein um was für einen Anwendungsfall es dann letztendlich geht, wa;)

Ich kann dir nicht im detail die gruende nennen, es gibt aber 0 artikel darueber das btrfs massiv ram braucht und 1mio das zfs viel ram braucht oder "will". Das ist fakt und hab versucht benchmarks zu finden, mit wenig ram, sah aber nur ein benchmark von 2013 auf phoronix wo mit 8gb ram (was ja viel ist) btrfs zfs zersaeegt hat. Ich wuerde wetten das bei 1-4gb ram die Benchmarks deutlich staerker noch zu gunsten btrfs gehen wuerden.
Nur weil es oft wo steht, muss es deswegen nicht korrekt sein. Ich habe selber viel über ZFS gelesen und bin zu dem Entschluss gekommen dass viele Seiten auch wenn sie über ZFS berichten sich nicht wirklich damit beschäftigt haben.
Es gibt zu ZFS eben auch verdammt viel halbwissen welches verbreitet wird und dies geschieht auch auf irgendwelchen IT-Seiten, wo Leute darüber nen Artikel schreiben, aber außer Windows und Apple nicht wirklich viel Ahnung haben.
Wenn du wirklich dir fundiertes Wissen aneignen willst, dann guck dich doch mal bei den Blogs um von ehemaligen ZFS Entwicklern. Die haben nunmal deutlich mehr Ahnung als "irgendjemand" im Internet der mal irgendwas gehört hat, oder nen eigenes NAS sich baut und sich selbst zum ZFS Experter erklärt. Im Hardwareluxx Forum gibt es auch einen riesigen ZFS Stammtisch. Da findet man auch Leute die sich wirklich damit auskennen.

Ich kenne keine seite die empfiehlt ne bestimmte menge von ram zu benutzen fuer btrfs, ich kenne seiten die das aber fuer ZFS tun.
Wenn eine Seite das für ZFS empfiehlt dann sollte es auch begründet werden können, notfalls steckt man 2GB, 4GB und 8GB in den Rechner und vergleicht. Aber einfach nur das kopieren was andere kopieren ist bisschen dünn findest nicht?
Dass viel Ram für ZFS empfohlen wird hängt auch sehr stark damit zusammen da es sich eher an den professionellen Einsatz richtet. Professionell heißt nicht nen NAS wo im Worst Case 2 User gleichzeitig drauf zugreifen.
Nen simples 2Bay NAS von Synology wird auch nicht da eingesetzt wo zig Zugriffe gleichzeitig stattfinden. Erwartet auch niemand, wieso dann bei ZFS auf einmal? Es skaliert eben, das ist alles. Willst du mehr Leistung benötigst du halt mehr Ressourcen. Hat aber nicht speziell was mit ZFS zu tun. Ich hab hier nen NAS das 4GB Ram besitzt, und nen anderes mit 9GB. Unterschied ist quasi keiner vorhanden, es ist sogar eher so dass das mit 4GB schneller ist, mag damit zusammen hängen weil die CPU stärker ist und weil 6 HDDs drin sind statt nur 2 bei dem anderen.
Und mal ehrlich, klar würde das Teil zusammen brechen wenn jetzt auf einmal 20 Leute auf einmal drauf zugreifen. Da würde es aber auch keien Abhilfe schaffen wenn ich Linux mit btrfs einsetze.
Obendrein kann dir ZFS sogar anzeigen ob mehr Ram bei deinem System in deinem Umfeld was bringt, bevor du den Ram reinsteckst. Schon oft erlebt dass bei 8GB zu 4GB einfach kein wirklicher Unterschied da war, rede hier von privater Nutzung.

Schoen und gut aber soll leute geben die nicht vollzeit systemadmins sind, die wollen mit ihrem pc arbeiten und nicht staendig das fs managen und beobachten.
Haha. Genau und bei Linux ist ja von der Benutzerfreundlichkeit genauso wie OSX, wa?
Das Problem ist viel mehr dass das du parteiisch bist und keine Lust hast dich damit zu beschäftigen weiter. Mit Linux haste dich aber auch einst auseinander gesetzt. Hat der normale DAU aber nicht, inwiefern soll das jetzt ein Argument sein?
Was du da ständig managen und meinst beobachten zu müssen ist mir auch rätselhaft. Du setzt beim Dateisystem die Einstellung und fertig ist. Was kreidest du hier an? Dass ZFS keine Gedanken lesen kann?

Was ich dann doch lächerlich finde ist etwas zerpflücken zu wollen wovon man bestenfalls Halbahnung hat.

Ich mein ich fasse deine Aussagen mal so zusammen: ZFS ist schlecht weil braucht soviel Ram, zumindest hast du das gelesen, woher du es herhast und ob die Leute überhaupt Ahnung haben von dem was sie schreiben, hast du aber nicht weiter verfolgt, weils dich nicht interesiert, du hast ja dein Argument gegen ZFS und alles ist in Butter.

Und du findest das ganze schwierig zu konfigurieren, weil du keine Lust hast dich damit auseinander zu setzen.
Wenn man von Windows oder OSX kommt wird man aber auch in Linux etwas Zeit reinstecken müssen um damit nen bisschen mehr zu machen als Video gucken, Surfen und emails lesen.
Aber anscheinend kennen sich die Leute von denen du sprichst von Kleinauf mit Linux bestens aus, scheinen jetzt aber plötzlich an ZFS zu verzweifeln lol

es kann sein du hast 30gb dateien auf deinem os aber es sind 80gb belegt, teilweise widersprechen sich die angaben auch. Mag ja auch sinnvoll sein, aber das ist ne umgewoehnug bei ext4 oder xfs schau bei df krieg eine anzeige die stimmt und gut, ich muss mich nicht mit 50 verschieden tools und anzeigen und der komplexen struktur des fs auseinandersetzen und alles ist recht simpel.
Genau 50 verschiedene Tools sonst geht gar nix. lol. Wo ist das Problem mit den Angaben? Wenn das OS irgendwelche Temp Dateien speichert wird auch auf einem "normalen" Filesystem der Platz weniger obwohl ich aktiv nix abspeichere.
Wenn du 30GB Daten hast, dann sind nunmal 60GB belegt wenn das fs alles doppelt speichern würde. Unter Windows gibt es da auch 2 Anzeigen, einmal für die Dateigröße selbst und dann auf den belegten Platz auf der HDD.
Wenn du viele kleine Dateien abspeicherst belegen die auch mehr Platz als die Dateien an sich. Bist du jetzt auch verwirrt? Finde das alles sehr abstrus was du schreibst, weils eben nicht so wirklich Sinn ergibt.

Dem DAU ist auch das mit der HDD egal. Der interesiert sich höchstens dann für die Festplatte wenn das OS ihm sagt ist voll.
 
Zuletzt bearbeitet:
Ilsan schrieb:
Nen simples 2Bay NAS von Synology wird auch nicht da eingesetzt wo zig Zugriffe gleichzeitig stattfinden. Erwartet auch niemand, wieso dann bei ZFS auf einmal? Es skaliert eben, das ist alles. Willst du mehr Leistung benötigst du halt mehr Ressourcen. Hat aber nicht speziell was mit ZFS zu tun. Ich hab hier nen NAS das 4GB Ram besitzt, und nen anderes mit 9GB. Unterschied ist quasi keiner vorhanden, es ist sogar eher so dass das mit 4GB schneller ist, mag damit zusammen hängen weil die CPU stärker ist und weil 6 HDDs drin sind statt nur 2 bei dem anderen.
Und mal ehrlich, klar würde das Teil zusammen brechen wenn jetzt auf einmal 20 Leute auf einmal drauf zugreifen. Da würde es aber auch keien Abhilfe schaffen wenn ich Linux mit btrfs einsetze.

Wenn ich das schon lese ein NAS also ne Netzwerkfestplatte mit 4 oder 9gb ram, die mit 9 oder meintest 8? waere dann schon kein nas mehr sondern ein Server wo du den speicher selber rein steckst, kostet schon zig hunderte Euro wenns was besseres sein soll schnell auch 4 stellig.

Das sind eher nicht das was die Masse an Leute kauft wenn sie NAS Systeme kaufen.

Du bringst nur keine Gegendarstellungen, du sagst halt ne andere Meinung mehr nicht, im ersten Post sagtest aber noch "das stimmt nicht" wenn das so waere wuerde ich gerne von dir links zu Benchmarks sehen, sonst wuerde ich sagen "ich glaube nicht das du recht hast weiss es aber auch nicht genauer".

Auch negierst du staendig das es einen unterschied auch nur geben koennte zwischen btrfs und zfs, woher nimmst du dieses wissen? Nur weil ichs dir nicht beweisen kann stimmt nicht automatisch deine Meinung.

Du gingst auch nicht auf die 128bit ein ist doch logisch das umso mehr bit etwa verarbeiten muss es um so verschwenderischer mit resourcen um gehen muss.

Auch scheint zfs nicht nur zu cachen es haelt auch immer viele daten im speicher die gar nicht dort sein muessten, soweit ich das verstanden habe, mags gruende geben fuer enterprise umgebungen ist ram billiger da verbraet man dann halt mal 1 2 gb ram zum Spass wenn dadurch 1% mehr speed raus kommt, das muss dann aber eben nicht fuer alle einsatzzwecke ideal sein.

Ich habe auch nicht so viel gegen zfs an sich, die Lizenz ist halt falsch und das ist dessen todesurteil, waere es gpl (v2), es war schneller "fertig" schoen, moeglicherweise hat es auch nieschen wo es auf dauer besser sein wird wie btrfs, ich seh nur nicht das freebsd linux verdraengen wird bei servern, daher wird nach und nach btrfs es ersetzen.

Aber das ist ein anderes thema, mich nervt nur wie du mit halwissen mein halbwissen verdraengen willst, ich habe glaub ich schon kenntlich gemacht, wo ich definitives wissen habe und wo ich ungefaehres halbwissen habe, du versuchst mich aber immer nur mit eigenem halbwissen oder dem bestehen auf beweise zu "widerlegen".

Du hast offenbar hardware da um vergleiche zu machen ich nicht. kannst mich gerne mit benchmarks widerlegen. Aber musst schon die platte relativ voll machen, bevor du benchmarkst, wenn du das tun solltest, denn die groesse der platte ist irrelevant wieviel belegt ist, ist nicht irrelevant.

Sollte das eine falschinformation sein, das zfs sehr viel speicher braucht um halbwegs vernuenftig zu laufen, ist das auch incht mein problem, dann haben die entwickler und alle extrem schlechtes Marketing gemacht, und dieses "Geruecht" oft selbst in umlauf gebracht, du kennst vielleicht jupiterbroadcasting und da gabs oder gibts ja auch bsd now show oder so ahenlich, dort kamen auch immer wieder zuschauerfragen, und dort wurde immer von 4 bisser 8 geredet.

Das mag daran liegen das der Host ein verwoehnter steinreicher Kerl ist der alles unterhalb von perfektion nicht als benutzbar ein stuft, aber das ist dann trotzdem ein Marketingproblem. Und wenn ich von tausenden quellen immerwieder das selbe hoere, dann mach ich mir nicht mehr die muehe das zu widerlegen, dann nehm ich erstmal an das das stimmt. denn das von 1000 quellen nur 1000 vollidioten dabei sind ist recht unwahrscheinlich.

http://geizhals.de/?cat=hdxnas&xf=3043_4096~2368_10#xf_top

gut bin da wohl nimmer ganz aktuell dezember 2015 hat wohl qnap guenstigere Modelle mit 4gb ram ein gestellt, das ist aber erst wenige monate her und 360 Euro ist auch nicht grad ein Papenstiel, war aber schon schlimmer, die nas firmen limitieren gerne kuenstlich den ram und verlangen abartige preise fuer bbisschen mehr ram, aber hei das kennen wir ja auch von smartphones und tablets.

NACHTRAG:

http://www.freenas.org/hardware-requirements/index.html
http://www.easynas.org/hardware-requirments/

das sollte doch alles sagen.
 
Zuletzt bearbeitet:
chithanh schrieb:
Verletzt wird die GPL, genauer gesagt der Passus, der besagt dass GPL-Code keinen weiteren Einschränkungen unterworfen werden darf, ferner muss Code der von der GPL abgeleitet ist, ebenfalls unter der GPL lizenziert sein.
Die CDDL von Solaris macht solche Einschränkungen und daher ist sie nicht zur GPL kompatibel.

Lösungen:
  1. Kernel-Lizenz wird geändert zu einer die CDDL-kompatibel ist, oder
  2. ZFS-Lizenz wird geändert zu einer die GPL-Kompatibel ist, oder
  3. beide ändern ihre Lizenzen (z.B. Kernel nach GPL v3, ZFS nach Apache 2.0), oder
  4. man sitzt das Problem aus nach dem Motto: wo kein Kläger, da kein Richter
Canonical scheint momentan auf letzteres zu setzen.

Es ist übrigens keinesfalls ausgeschlossen, dass der Kernel seine Lizenz ändert. Zwar müssten alle Copyrightinhaber (bzw. deren Erben) zustimmen, und die Teile für die man keine Zustimmung bekommt neu geschrieben werden. Aber da mit jedem Kernel-Release sowieso erhebliche Teile neu geschrieben werden ist das im Bereich des Möglichen.

Damit wiederholtst du nur mit anderen Worten das was in dem Artikel steht. Warum das ein Problem sein soll wenn beide Produkte auf unterschiedliche Lizenzen aufsetzen wissen wir immer noch nicht
 
Ich bin ein Linux-Noobie fand den Artikel aber verständlich, finde wenn man sich etwas mit dem Aufbau von einem Betriebssystem und freier Software beschäftigt hat weiß man auch worum es geht. Ansonsten einfach mal zwei Begriffe in die Suchmaschine hauen. ;)
 
Die Idee ZFS als Dateisystem in einige Linux-Distributionen zu integrieren empfinde ich aus Sicht privater Nutzer sehr interessant. Häufig basieren die NAS Systeme von Freunden auf Basis von ausgedienten Unternehmens-RAID-Controllern die sie günstig geschossen haben. Wenn die NAS' dann über den Jordan gehen ist die Panik groß, weil es meistens nach einer Platte dann irgendwann der Controller ist.

Durch ZFS (setzt ich selbst für meine Backup-NAS ein) erhält man eine robuste Software die sich durch Snapshots Ideal für derartige Archivierung anbietet. Betreibe das bei Bedarf (Backup) auf einem älteren Serverboard mit ECC Speicher. Die Performance (nur 4 TB @RAIDZ) ist mit 8GB RAM sehr gut und das System hat aus schon einen Plattenausfall überstanden.

Es ist absolut erforderlich den Ernstfall vorher zu trainieren um im Ernstfall souverän handeln zu können. Sonst begrüße ich den Versuch Seitens Canonical, verstehe den Gegenwind aber sehr wohl. Die post-Installations-Integration des ZFS Dateisystems ist imho aber auch nicht schwer, sodass ich den Punkt nur als eingeschränkt kritisch sehe. Die Funktionalität bekommt ihr auch so auf euer System, ohne die Hilfe von Canonical.

Viele Grüße
 
Mr.Seymour Buds schrieb:
Gerade bei Linux hat man ja mehr Auswahl, als zB Windows mit "nur" NTFS...

Weils viele nicht wissen: Auch unter Windows kannst man verschiedene Dateisysteme nutzen, wenn sich jemand ransetzt und sowas auf Windows portiert.

Das wurde bereits mit ext2 gemacht (www.fs-driver.org) und BTRFS ist auch schon in der Mache: BTRFS für Windows

Nur weil Microsoft etwas nicht anbietet, heißt das nicht dass es nicht geht. Es fehlt fast immer nur an der Bereitschaft etwas für Windws umzusetzen. Windows wird sich auf solchen Dateisystemen natürlich nicht installieren lassen. Da muss immer NTFS verwendet werden. Weitere Partitionen oder Platten können aber durchaus mit diesen anderen Dateisystemen versehen werden.
 
tek9 schrieb:
Damit wiederholtst du nur mit anderen Worten das was in dem Artikel steht. Warum das ein Problem sein soll wenn beide Produkte auf unterschiedliche Lizenzen aufsetzen wissen wir immer noch nicht

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. Die anderen Anwälte sehen das anders, 2 Anwälte zwei Meinungen halt. Welcher Passus das nun genau ist -> who cares? Ändert sich für dich etwas wenn du es weißt? Jemand anderes als ein Softwareanwalt steigt da eh nicht durch :D

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 ;)
 
Zurück
Oben