ZFS auf FreeBSD

Wie ist das, darf für die BSDs der original ZFS-Quellcode von Sun benutzt werden?
Ich hab was von Lizenzproblemen mit Linux gelesen und hoffe jetzt, dass diese für die BSDs nicht existieren! :)
 
Ja, ZFS steht unter der CDDL, da gibt es keine Lizenzprobleme in/mit FreeBSD und sicher auch nicht mit anderen BSD-Projekten ausser vielleicht OpenBSD (ich kenne die Meinung von Theo zur CDDL nicht). Matt Dillon/DragonFly BSD arbeitet ja auch seit geraumer Zeit an einer ZFS-Implementierung, kaum aber wohl zeitlich nicht dazu. Wenn ZFS in FreeBSD Einzug gehalten hat wird es auch in anderen BSDs adoptiert werden, davon gehe ich aus.

Linux hat das in Fuse sprich userland verbannt, weil die Leute dort (darüber lässt sich trefflich streiten) der Meinung sind, daß die CDDL nicht mit der GPL kompatibel sei, weil die FSF mal die CDDL als nicht-kompatibel zur GPL einklassifiziert hat.

Anyway. Pawel arbeitet seit 10 Tagen daran und lässt offensichtlich mal wieder richtig die Sau raus, ein Hoch auf Pawel! Geom in Verbindung mit ZFS könnte richtig rocken. :)
 
Mann... ich kann's gar nicht erwarten. Ein neuer LVM wäre echt cool.

Kann jemand einige Firmen auftreiben, die etwas spenden könnten?
 
Daniel Seuffert schrieb:
Ja, ZFS steht unter der CDDL, da gibt es keine Lizenzprobleme in/mit FreeBSD und sicher auch nicht mit anderen BSD-Projekten...
Zum Vergrößern anklicken....
... weil die Leute dort (darüber lässt sich trefflich streiten) der Meinung sind, daß die CDDL nicht mit der GPL kompatibel sei...
Zum Vergrößern anklicken....
Wie ich das so, vor längerem, beiläufig mitbekommen habe gab/gibt es auf Seiten von Net-/OpenBSD "ernsthafte Bedenken" hinsichtlich der Lizenz. Da gab es einige Stimmen die Zweifel an der Verwendung der CDDL anmeldeten. Nicht nur im Hinblick auf auf die GPL, vielmehr auch in Bezug auf die BSD-Lizenz. Tut mit leid aber daß Klang alles nicht nach "eitel Sonnenschein".
Eine Äußerung von Theo de Raadt konnte ich so auf die schnelle nicht finden...
 
Wie wir alle wissen sieht, das die FreeBSD-community etwas lockerer als unsere NetBSD- oder gar OpenBSD-Freunde. Nichtsdestotrotz wandert der originäre Sun-part ja nach contrib, wie Pawel ja in seiner mail auf current auch explizit verlauten lies, quote daraus:

I'm doing my work in those directories:

contrib/opensolaris/ - userland files taken directly from
OpenSolaris (libzfs, zpool, zfs and others)

sys/contrib/opensolaris/ - kernel files taken directly from
OpenSolaris (zfs, taskq, callb and others)

compat/opensolaris/ - compatibility userland layer, so I can
reduce diffs against vendor files

sys/compat/opensolaris/ - compatibility kernel layer, so I can
reduce diffs against vendor files (kmem based on
malloc(9) and uma(9), mutexes based on our sx(9) locks,
condvars based on sx(9) locks and more)

cddl/ - FreeBSD specific makefiles for userland bits
Zum Vergrößern anklicken....

Auf OpenBSD übersetzt würde das in attic landen z.B. vermutlich. Die CDDL ist nicht kompatibel zur 2-clause BSD-license ohne Zweifel, das hindert aber weder die Entwicklung noch den Einsatz von ZFS.

Ob und inwieweit andere BSDs die Arbeit von Pawel und anderen aufgreifen werden steht natürlich noch in den Sternen, ich gehe davon aus, daß dies schlicht von der Bedeutung/Erfolg von ZFS an sich abhängt. Und selbst "BSD-Faschisten" wie unsere OpenBSD-Brüder und Schwestern kümmern sich ja bereits um OpenOffice nativ, also da ist imho noch kein definitiv negatives Wort auch nur annäherungsweise gesprochen. Wenn ZFS sich durchsetzt wird die Lizenzproblematik selbstverständlich ausgiebigst in ungezählten bikesheds diskutiert werden, aber es gibt eben keine Kroah-Hartmanns in BSD so far. :D

Disclaimer: No offense meant to anybody, peace... :)
 
Wie genau ist sie inkompatibel? Gibt es da schon ne Analyse zu?
Ich habe gerade mal versucht die CDDL genauer zu studieren, aber die geht mir dermaßen auf den Keks. Das nervt einfach nur. Ist fast so schlimm wie die GPL.

Ich gründe hiermit die BOSI, die Better OpenSource Initiative. Wir lehnen jegliche Lizenz außer der 2-clause BSD-Lizenz ab! ;)
 
afaik, ist die CDDL einfach eine neue copyleft lizenz.
der unterschied zur GPL (und was sie mit dieser inkompatibel macht), ist das die CDDL wohl das erwähnen, jedes einzelnen mitwirkenden im copyright verlangt...
die bsdl ist natürlich zur CDDL "kompatibel" (andersrum natürlich nicht).

kompliziert wird das ganze für freebsd erst, sobald das freebsd-projekt cddl und gpl-lizensierten code in GENERIC aufnehmen wollen würde.
 
Maledictus schrieb:
Wie genau ist sie inkompatibel? Gibt es da schon ne Analyse zu?
Ich habe gerade mal versucht die CDDL genauer zu studieren, aber die geht mir dermaßen auf den Keks. Das nervt einfach nur. Ist fast so schlimm wie die GPL.
Zum Vergrößern anklicken....


Eine genaue Analyse ist mir nicht bekannt, ich habe die CDDL mal ansatzweise durchgelesen aber es geht mir wie dir: Alles was mehr als 3 Sätze als Lizenz hat ist nicht strukturiert genug. Und ich habe einfach Null Bock mir tagelang Gedanken zu machen was ich nun mit freier software machen darf oder nicht, entweder sie ist frei oder nicht. :grumble:

Die BSD-Lizenzen (2-, 3-, 4-clause) sind halt neben public domain die absolut freiesten Lizenzen. CDDL ist dahingehend inkompatibel zu BSD weil es schlichtweg wesentlich mehr Klauseln sind, daher landet es ja bei FreeBSD in contrib. Aber ansonsten stört mich die CDDL nicht, weil der extrem virale Charakter der GPL fehlt. Advertising clauses sind in meinen Augen überflüssig, aber von mir aus, wers braucht: Bitte. Wir respektieren bei FreeBSD jede Lizenz, wenn wir die software als wertvoll genug erachten, und gut ist. Aber wir halten das in engen Grenzen und beschmutzen unseren Kernel nicht damit. Und das ist ja exakt das, was die GPL-Jünger auch tun.

Die CDDL ist auch nicht so ein großes Problem, weil es relativ gesehen weniger code darunter gibt als z.B. unter GPL, das ist schon eine Frage der schieren Masse. Ausser DTrace, ZFS, vielleicht Java wenn es OSS wird und ein paar anderen Dingen wird es in BSD kaum größere Berührungspunkte zur CDDL geben, zumindest nach heutigem Stand.
 
daniel schrieb:
Aber ansonsten stört mich die CDDL nicht, weil der extrem virale Charakter der GPL fehlt.
Zum Vergrößern anklicken....
die CDDL ist auch copyleft, d.h. änderungen landen unter derselben lizenz. aus der lizenz selber geht nicht genau hervor, ob das linken mit CDDL code, das eigentliche werk zu einem "derived work" macht, ich denke aber, dass das der fall ist. der "virus effekt" wäre hier also genauso.
oder meinst du etwas anderes damit?

edit: übrigens wird der "virale charakter" der charakter der gpl von vielen bsdlern überschätzt. die GPL zwingt niemanden die GPL statt der BSDL zu benutzen. auch in derived works oder mit gpl-bibliotheken, bleibt jedem entwickler immer die möglichenkeit seinen beitrag unter BSDL zu veröffentlichen. sein beiträg benötigt danach lediglich eine gpl-komponente. der code selber könnte auch aus dem projekt herausgenommen oder ohne die GPL-komponente unter anderen lizenzen (auch proprietär) weiterverbreitet werden.
 
Zuletzt bearbeitet:
@soul_rebel: Ich beziehe mich auf http://www.opensource.org/licenses/cddl1.php im Folgenden. Klar steht da, daß ein derived work auch unter den Bedingungen der CDDL wieder steht, aber von linken oder dergleichen lese ich nichts und was nicht explizit geregelt ist gilt in meinen Augen als frei machbar. Zumindest einen Vorteil hat die CDDL wirklich: Sie ist wesentlich kürzer/einfacher als die GPL. Und was den viralen Charakter betrifft: Jede Zeile Code, welche von BSD in GPL einfliesst ist ein Marsch in eine Einbahnstrasse, weil nur GPL-Code zurückkommen kann (natürlich kann man das geänderte Werk zumindest ansehen und Ideen usw. übernehmen).

Aber beenden wir bitte hier die ewige und stinklangweilige Lizenzdebatte und kümmern uns um das, was BSD bedeutet: Freier, funktionaler, sicherer, schöner code. Die Frage von Dinh ist imho ausreichend beantwortet: Es gibt zumindest in FreeBSD keine Lizenzprobleme bei der Implementierung von ZFS.

Also nochmals ein Dank an Pawel für seine tolle Arbeit und hoffentlich wird er bald damit fertig und es ist genauso gut wie seine anderen Sachen. :)
 
Daniel schrieb:
Jede Zeile Code, welche von BSD in GPL einfliesst ist ein Marsch in eine Einbahnstrasse, weil nur GPL-Code zurückkommen kann
Zum Vergrößern anklicken....
stimmt aber nicht. du kannst projekt A schreiben, welches du unter der BSDL veröffentlichst, auch wenn du mit Bibliothek B linkst, die unter GPL steht. rechtlich gesehen, steht zwar das gesamte werk dann unter der GPL, aber dein teil kann auch unter einer anderen lizenz stehen, wenn diese die regeln der GPL nicht verletz.
als gründer des projekts kannst du als bedingung machen, dass dazufließender code unter der BSDL stehen muss, dann kann jeder mensch jederzeit dein Projekt A nehmen und daraus was unfreies/anders-lizensiertes machen, wenn er die abhängigkeit zu der einen GPL-bibliothek abschafft (z.b. sie durch eigenen code ersetzt).
zugegeben, wenn es nicht ums linken geht sondern um arbeit an einem stück code, wird es schwierig da später herauszuklamüsern, welche stück code den restriktionen der gpl nicht unterliegt, aber wenn es einem wichtig ist kann man das ja markieren...

aber ich freue mich auch auf zfs :)

und ich hoffe dass wir bald in den genuss einer stabilen implementierung kommen...
 
Ich hab noch 'ne kleine Frage, wenn's euch nicht zu sehr nervt. :)

Daniel Seuffert schrieb:
Aber wir halten das in engen Grenzen und beschmutzen unseren Kernel nicht damit. Und das ist ja exakt das, was die GPL-Jünger auch tun.
Zum Vergrößern anklicken....
Heisst das, dass die ZFS-Implementierung nicht in den Kernel kommt - oder meinst du damit einfach, dass nicht bsdl-Code sonst eher selten in den Kernel fliesst?


Und noch was: denkt ihr, dass ZFS irgendwann UFS ablösen und zum neuen 'Hauptdateisystem' werden könnte?
 
@Dinh:

1. Nicht-BSD-code kommt nicht in den Kernel sondern nach contrib, egal ob GPL, CDDL oder sonstwas.

2. Die BSD-spezifischen Teile von ZFS kommen natürlich in den Kernel, sprich das was der Pawel oder andere da unter BSD-license programmieren.

3. Der Rest, der von OpenSolaris kommt, in die Verzeichnisse eben die Pawel auch in seiner mail aufführt.

4. Ob ZFS jemals UFS ablösen wird wage ich momentan sehr zu bezweifeln, zumindest nicht in mittelbarer Sicht. Es ist/wird eben ein weiteres filesystem wie all die anderen bestehenden. Ich glaube das könnte nur geschehen, wenn ZFS sich als so überragend und auf vielen Plattformen bewährt, daß man sagt man verzeichtet auf die Weiterentwicklung von UFS völlig. Aber wer die konservative Art der BSD-Mannen kennt weiß, daß dies nur unter extremen Umständen und in vielleicht 10 Jahren passieren würde. Selbst wenn ZFS heute fertig wäre, würde doch jeder vernünftige Mensch erstmal 2-3 Jahre abwarten, bis er seine Produktivsysteme darauf aufsetzt, ich jedenfalls würde so handeln.
 
Im Nachgang dazu ein kleines update von Pawel von heute auf current. Er sagt zwar, daß er in der Weiterentwicklung momentan durch andere Dinge etwas gebremst ist, aber wenn man sich http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/pjd/zfs und View Changes anschaut, dann sieht man wie rasch er vorankommt. Der Mann ist ein Tier. :)

Aus seinen mails von heute auf current:

All file system operations seems to work. The only exception are
operations needed for mmap(2) to work. Bascially file system works quite
stable even under heavy load. I've problem with two assertions I'm
hitting when running some heavy regression tests.

I've spend a couple of days fighting with snapshots. To be able to
implement them I needed to port GFS from Solaris (Generic
pseudo-filesystem). Now, snapshots (and clones) seems to work just fine.

Some other minor bits like zpool import/export, etc. now also work.

File system is not yet marked as MPSAFE (it still operates under the
Giant lock).
Zum Vergrößern anklicken....


Auf deutsch: Fast alle Operationen laufen bis auf mmap(2) (wer nicht weiß was das ist: es gibt ne manual page dazu), snapshots funktionieren nach dem porten von GFS aus OpenSolaris und selbst unter hoher Last läuft das ganze stabil, nur mit GIANT-lock momentan. Bevor die Frage nach ersten patches kommt, die user selbst testen können erklärt Pawel im Nachgang dazu:

And one more very important thing! The code is not yet ready for testing
by others, so please don't ask for patches. When the code will be ready
I'll publish them.
Zum Vergrößern anklicken....


Auf gut Deutsch: Patches für die Allgemeinheit gibt es dann, wenn es soweit ist. Das überrascht uns als BSD-user nicht wirklich.

Ich hoffe das geht in diesem Tempo weiter, Hut ab vor Pawel und dem, was er in der Kürze der Zeit geschafft hat!
 
Ich mache mal hier weiter, da ein weiterer thread imho nicht nötig ist. Pawel hat heute auf current bekanntgegeben, daß der erste working patch bereitsteht, natürlich gegen current. Ich spare mir weitere Ausführungen und zitiere den Meister persönlich:

Date: Thu, 16 Nov 2006 02:59:08 +0100
From: Pawel Jakub Dawidek <pjd@FreeBSD.org>
Subject: ZFS patches for FreeBSD.
To: freebsd-fs@FreeBSD.org
Cc: freebsd-current@FreeBSD.org
Message-ID: <20061116015908.GB63195@garage.freebsd.pl>
Content-Type: text/plain; charset="iso-8859-2"

Hi.

This is a first set of patches, which allows to use ZFS file system from
OpenSolaris on FreeBSD.

To apply the patch you need to have recent FreeBSD source (be sure you
have rev. 1.284 of src/sys/kern/kern_synch.c).

To try it out you need i386 machine (this is what I tested) and kernel
without WITNESS compiled in (there are probably some warnings still).

Currently it can only be compiled as a kernel module.

To apply the patch you need the following steps:

# cd /usr/src
# mkdir -p cddl/lib/lib{avl,nvpair,umem,uutil,zfs,zpool}
# mkdir -p cddl/usr.bin/ztest
# mkdir -p cddl/usr.sbin/{zdb,zfs,zpool}
# mkdir -p compat/opensolaris/{include,misc}
# mkdir -p contrib/opensolaris/cmd/{zdb,zfs,zpool,ztest}
# mkdir -p contrib/opensolaris/common/{acl,avl,nvpair,zfs}
# mkdir -p contrib/opensolaris/head
# mkdir -p contrib/opensolaris/lib/libnvpair
# mkdir -p contrib/opensolaris/lib/lib{uutil,zfs}/common
# mkdir -p contrib/opensolaris/lib/libzpool/common/sys
# mkdir -p sys/compat/opensolaris/{kern,machine,rpc,sys}
# mkdir -p sys/contrib/opensolaris/uts/common/fs/zfs/sys
# mkdir -p sys/contrib/opensolaris/uts/common/{os,rpc}
# mkdir -p sys/contrib/opensolaris/uts/common/sys/fm/fs
# mkdir -p sys/contrib/opensolaris/uts/common/sys/fs
# mkdir -p sys/modules/zfs
# fetch http://people.freebsd.org/~pjd/patches/zfs_20061117.patch.bz2
# bzip2 -d zfs_20061117.patch.bz2
# patch < zfs_20061117.patch
# make buildworld
# make kernel
# make installworld
# kldload zfs.ko
(zfs and zpool command should work now)

Before reboot:
# zfs export <your_pool>

After reboot:
# kldload zfs.ko
# zfs import <your_pool>

After a panic:
# kldload zfs.ko
# zfs mount -a
# zfs volinit

Most of the functionality should work, but there are exceptions.

zfs share/unshare don't work yet, you also won't be able to export ZFS
files systems via NFS.

ACLs don't work yet.

The ZFS file system is MPSAFE (it operates without the Giant lock), but
performance isn't quite there yet. Please do not report that it is
slower than UFS, etc. I know it is. On the other hand you should report
if there are some huge differences in performance between UFS and ZFS,
for example if ZFS is few times slower in some workloads.

Under very heavy load (or maybe even under not that heavy load, but
after a longer time) it may panic with
"kmem_malloc(X): kmem_map too small: Y total allocated"
message. The back-presure mechanism doesn't work well and SUN guys are
helping me to figure out why. If you see such panic, please do not
report it, just reboot your machine and continue (or not).

Please do report any other strange panics or situations (like various
commands not working as they should, you see strange file system
behaviour, etc.), _but_ before reporting any issue, verify that it
wasn't already reported on freebsd-fs@FreeBSD.org mailing list.

If you have any questions or comments, I'd prefer if you send them to
the mailing list instead of me privately, as it's quite possible others
would like to know too.

Good luck and enjoy!

Big thanks to ZFS developers for great work and to SUN for opening ZFS
source!
Zum Vergrößern anklicken....


Der Mann ist einfach ein Tier! :) Vieles wird natürlich noch nicht richtig gehen, also seid so nett und meldet bugs usw. direkt auf freebsd-fs@FreeBSD.org, damit alle mitbekommen, wo man noch Hand anlegen muß. Wie man unseren geliebten Pawel kennt wird es nicht allzulange dauern, bis ZFS läuft und man muß wirklich kein Prophet sein, um zu erkennen, daß nach aller Wahrscheinlichkeit in FreeBSD 7.0 ein funktionierendes ZFS zur Verfügung stehen wird. Also wer Zeit und Lust hat: Mitmachen! Und bitte keine Backups vergessen bzw. gleich Testkisten verwenden, ich schreibe das nur, damit es nicht hinterher Geschrei gibt, wenn etwas nicht so funktioniert wie erhofft. Das Zeug ist fertig, wenn es fertig ist! :belehren:


An dieser Stelle auch von mir ein Dank an Sun und all die freiwilligen Entwickler bei OpenSolaris, die dies möglich gemacht haben! :) Wir sollten nicht vergessen, daß ZFS selbst ziemlich jung ist und auch dort wird es noch viele Verbesserungen geben, die natürlich auch in FreeBSD einfliessen werden, allerdings stehen für Pawel momentan andere Dinge im Vordergrund, daher kein Import von Neuerungen vorerst.
 
Wie sieht es denn im Moment mit der ZFS Entwicklung aus?
Wäre es mit der FreeBSD 8er sinnvoller ZFS zu nutzen?
 
ich nutze es mit 7.2 Release, also mit Version6 auf einem amd64 mit 4GB Ram und es ist das Raid-System für meinen Fileserver. FreeBSD 7-Stable oder 8 bislang booten leider nicht von dem USB-Stick, auf dem ich mein System liegen habe.
Also, mein System liegt auf einer Partition eines Sticks, die ist UFS und die exportierten Daten für die verschiedenen Dienste auf dem ZFS Raid.
Außer einem Blitzschaden und meinen gelegentlichen Versuchen mit anderen Systemen (auch OpenSolaris will einfach nicht mit dieser HW vom Stick booten), gab es bisher nicht einen einzigen Aussetzer des Servers. Überhaupt gar keinen. Und gar keinen Fehler des ZFS oder sonstwie des Dateisystems.
Es ist zwar eigentlich immer noch ein Bastel-Server, aber in meinem Haushalt greifen über verschiedene Dienste Mac-OS-X, GNU/linux, busybox/Linux und FreeBSD Systeme darauf zu und es läuft auf dem Server ein ziemlich intensiver VLC als Server, der fergesteuert Filme umwandelt und streamt und trotzdem: nicht ein einziger Fehler, nur belangloses Zeugs, wie:
Aug 26 19:44:08 files inetd[962]: netbios-ssn/tcp: bind: Address already in use
Aug 26 19:44:08 files inetd[962]: ssh/tcp: bind: Address already in use
Aug 26 19:54:02 files inetd[962]: netbios-ns/udp: bind: Address already in use
Aug 26 19:54:02 files inetd[962]: netbios-ssn/tcp: bind: Address already in use
Aug 26 19:54:02 files inetd[962]: ssh/tcp: bind: Address already in use

Also, meiner Meinung nach: Ja, ZFS, wirklich ganz toll!
Musste zwar erst überredet werden, doch bin nun geradezu ungestüm begeistert. Gegenüber allen anderen Versionen, die ich probierte, ist es einfach und genial gut.
Wenn es die Möglichkeit gibt, ZFS 13. Ich probierte es mit OpenSolaris und FreeBSD und importierte meinen Raid jeweils dort und es war spürbar, dass weniger Speicher belastet wurde.
 
Ist es entscheidend schnellen und viel RAM für ZFS zu haben, wenn ich es unter FreeBSD laufen lassen will?
 
lockdoc schrieb:
Ist es entscheidend schnellen und viel RAM für ZFS zu haben, wenn ich es unter FreeBSD laufen lassen will?
Zum Vergrößern anklicken....

"Schnell" ist nicht so das Kriterium (DDR2 tut's locker auch), aber "viel" sollte es auf jeden Fall sein. Für den produktiven Einsatz rechne ich bei einem Terabyte Poolgröße mit ca. 2 GB RAM nur für ZFS. Die werden zwar nicht immer voll ausgeschöpft, aber die Speicherverwaltung bei ZFS ist etwas merkwürdig gelöst (Threads können beliebig viel Speicher allokieren; Speicher, der über die gesetzten Limits hinausgeht, wird erst im Nachhinein von einem Ausputzer-Thread wieder freigegeben). Daher können schon mal ziemliche Spitzen entstehen, die zwar nur sehr kurz existieren, aber ein kmalloc(), das ins leere greift, ist halt sehr unschön.

Dazu kommt dann noch der Speicher für den Rest - sonstige Kernel-Prozesse und natürlich das Userland. Je nachdem also nochmal 2 bis 6 GB. Auf einem reinen File-Server reichen 4 GB aus, auf einem DB-Server dürfens ruhig 8+ GB sein. Das heißt natürlich in jedem Fall, dass i386 raus ist - bei ZFS ist amd64 das Gebot der Stunde.
 
Inzwischen kann ZFS auf FreeBSD "Backpressuring", es kann also belegten Speicher wieder freigeben, sobald jemand anders ihn benötigt. Das macht das ganze auch mit weniger Speicher benutzbar. Aber damit es wirklich performant und auch in Extremsituationen stabil läuft, solltest du dich schon an den Zahlen von Ogion orientieren. Grundsätzlich gilt halt, gegen zu viel RAM hilft nur noch mehr RAM :)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben