Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 94 reacties

Apple werkt niet langer aan de ontwikkeling van het Zettabyte File System voor zijn OS X-besturingssysteem. Het toepassen van het door Sun ontwikkelde zfs-filesystem draagt mogelijk te veel juridische risico's met zich mee voor Apple.

ZFS Apple-styleDe mededeling dat Apple stopt met het zfs-project is te lezen op Macosforge, een website waar ontwikkelaars samenwerken aan opensource-projecten. Niet alleen zijn de webpagina's van het zfs-project verwijderd, op korte termijn zullen ook de bijbehorende mailinglist en repository's worden gesloten.

Het 128bit opensource bestandssysteem zfs is ontwikkeld door Sun en zou schaalbaarheid en databeveiliging als sterke punten hebben. In juni 2007 stelde Jonathan Schwartz, de toenmalige directeur van Sun, dat Apple zfs zou hebben verkozen als hét filesystem voor Mac OS X 10.5, maar Apple liet al vrij snel weten dat zfs uitsluitend optioneel te gebruiken zou zijn naast zijn eigen hfs+-bestandssysteem. In januari 2008 gaf Apple nog wel de broncode vrij van zijn OS X-implementatie, maar ook bij de lancering van de laatste OS X-versie Snow Leopard was ondersteuning voor zfs afwezig. Apple bleef zelf angstvallig stil over de status van zijn zfs-project.

De precieze redenen waarom Apple definitief de stekker uit zijn zfs-project heeft getrokken, zijn onduidelijk, maar vermoedelijk spelen onder andere juridische aspecten mee in de beslissing. Vorig jaar besloot de firma Netapp een patentzaak over zfs aan te spannen tegen Sun. Om niet zelf het risico te lopen aangeklaagd te worden wegens het schenden van patenten, heeft Apple mogelijk afgezien van het bestandssysteem. Daarnaast is Sun overgenomen door Oracle. Mogelijk zal Oracle besluiten om de doorontwikkeling van zfs te staken, waardoor de toekomst van het filesystem er weinig zonnig uitziet.

Moderatie-faq Wijzig weergave

Reacties (94)

John Gruber:
Best piece on the Apple/ZFS/next-gen-FS situation I’ve seen anywhere, spanning everything from the potential licensing problems to the technical ways that ZFS is not ideal for Apple’s needs.
http://devwhy.blogspot.com/2009/10/loss-of-zfs.html
Met veel tweakers gerelateerde zaken; wat we niet kennen, kunnen we ook niet missen :P (zie mac vs windows). ZFS zal op papier met alles beter/geavanceerder/ etc zijn. Maar wat wil een tweaker? windows en een paar games installeren, plug nog 100en tot terrabytes aan media opslaan. Boeit dan het filesystem echt? nein, niet echt.

ontopic:
Ik zat te denken om een paar dingen van wikipedia te vertalen, weettoch, met die +2 of +3 weglopen, maar ik heb al genoeg/teveel karma. Dus ik laat dat over aan een andere tweaker O-)
Zeker voor het naar wens aankopplen van extra schijven is ZFS een enorme verbetering tegenover NTFS. Met NTFS moet je raid oplossingen gaan verzinnen en dan kun je niet on the fly extra schijven aankoppelen.

Met NTFS moet je bedenken "had ik deze film nu op E:\films, of op F:\films of toch op G:\extra\films opgeslagen"? Met ZFS heb je gewoon 1 gigantische storage pool met ingebouwde redundantie, checksumming, etc. Met genoeg schijven kun je er zelfs gewoon 1 uit trekken en alles blijft gewoon werken, je merkt het niet eens.

ZFS heeft zeker wel enorme voordelen voor tweakers, JUIST voor tweakers. Ik heb het over de data integriteit, ingebouwde snapshots en block-level backups en synchronisatie (zfs send/receive) nog niet gehad.
Je kunt toch gewoon een schijf(partitie) als volume koppelen in NTFS?
Ik heb geen raid config op deze bak, maar aan mijn temp dir. zit gewoon een 500 GB schijfje gekoppeld.
Of bedoel je dat niet?
Dat bedoel ik niet nee. Wat als je nu twee schijven wilt combineren tot 1 locatie in je directory structuur? Kun je dat ook met NTFS?

Of wanneer je 4 of 5 schijven hebt, die allemaal als 1 grote schijf zien. En dan een extra schijf aankoppelen wanneer het vol dreigt te raken. Met RAID kunnen dat soort dingen wel, maar bij ZFS zit het in het filesystem ingebouwd, geen raid controllers, geen hardware support, geen moeilijkheden. Gewoon schijf toevoegen aan je storage pool en je hebt meer ruimte.

Met andere systemen zijn soortgelijke zaken ook mogelijk (linux lvm2 bijvoorbeeld, spanning volumes op NTFS mogelijk ook lees ik hierboven), maar met ZFS gaat het in mijn ervaring allemaal een stuk makkelijker.

Dit alles vanwege de "blatant layer violations" die ZFS doet, zoals genoemd in de link in de eerste reactie.
Wat jij bedoelt is wat linux altijd al kon, gewoon mountpoints e.d. Wel leuk dat je dat weet, bijna geen enkele 'fake-tweaker' om het zo te noemen weet dat (lees: gamers die soms zelf een videokaart in hun dell proppen - niet dat ik jou of iemand hier daar toe reken). En dan te bedenken dat ze windows als nog totaal verdedigen zonder ook maar een redelijk stukje kennis te hebben :)

On topic:

Gewoon wat mountpoints gebruiken kan ja, maar dan heb je bijv. dat je perongeluk wat bestanden in de mountpoint zet en als je dan mount dat dingen dubbel zijn.. (Union FS op linux lost dat op, weet niet hoe windows dat doet), of als je schijf failt, dan zegt windows: jammer dan.

Ga je 10 HDD's aansluiten in een pool met maximale redundantie, dan rop je d'r een uit en kan je weer door. Probeer dat maar eens met een leuke NTFS spanned volume op een leuk mountpointje ergens.. (of op zo'n achterhaalde "Drive letter") Gaat niet goed komen :)
Ik bedoel geen mountpoints. Dat is een heel ander concept wat slechts zijdelings aan Zfs gerelateerd is.

Een mountpoint kan naar een zfs volume wijzen ja, ook naar een fysieke schijf of een loopback device of een hele berg andere dingen.

En veel "tweakers" weten daar inderdaad niet van af, maar ik zie niet in wat dat met deze discussie te maken heeft.
Ja, je kunt volumes mounten (en trouwens ook softlinks maken naar directories op andere schijven). Maar een file staat nog wel maar in 1 filesystem, op een enkele partitie. Je kunt niet zomaar een andere disk toevoegen en dat je dan op c: ineens meer schijfruimte hebt.
Zou wel moeten kunnen als de disk als 'dynamic disk' is aangemaakt waarop je C: staat.
Dan zou het mogelijk moeten zijn om een andere dynamic disk te gebruiken om je C: te 'spannen' over die 2e disk (on-the-fly).

Maar het blijft nog steeds onhandig: een schijf weghalen is niet meer mogelijk zonder je filesystem te beschadigen zover ik weet.

Mijn voorkeur gaat nog altijd uit naar de LVM implementatie die bij IBM AIX wordt gebruikt:
- makkelijk disks toevoegen en verwijderen in je VG
- filesystems on-the-fly vergroten en verkleinen, zonder te moeten unmounten
- data (je LV) verplaatsen van een schijf af
- etc...

Weet iemand of dit ook met bv een EXT4 of ReiserFS4 onder Linux kan (dus zonder unmount)?
LVM is bij Linux een aparte laag, die je bijv. tussen je software-RAID en je filesystem in zet. Je lijstje met mogelijkheden kan ook gewoon met Linux.

Alleen het online krimpen van bestandssystemen is bij de meeste filesystems, zoals bijv. XFS en ReiserFS, niet mogelijk. En als je het filesystem niet kleiner kunt maken kun je ook het onderliggende LV niet krimpen.
Zou wel moeten kunnen als de disk als 'dynamic disk' is aangemaakt waarop je C: staat.
Dat is géén feature van het filesystem maar gewoon software RAID (of eigenlijk JBOD)
Ik ben toch erg benieuwd waarom je zo'n enorme temp dir zou willen... :)
Als je een SSD hebt als bootschijf en je gebruikt bijvoorbeeld video-editing applicaties die nogal wat temp-data wegschrijven (tussen-renders enzo), dan kan het slim zijn om daar een externe schijf voor te gebruiken en je temp-directory (vaak heet het dan scratch-directory) daar neer te zetten. Komt de levensduur van de SSD ten goede :)
Exact !!
Zo zit ik ook te kloten met meerdere externe USB disks. En waar stond nou ook weer die muziek, dat bestand, etc.?
Een fatsoenlijke oplossing hiervoor zouden ook Windows gebruikers niet erg vinden.
Edit: typo

[Reactie gewijzigd door Permutor op 25 oktober 2009 12:40]

spotlight

command+spatie "bestandnaam" (of woord uit bestand) et voila.
command+enter als je de map wil openen waar de file in zit ipv de file.

Ik weet zeker dat windows inmiddels ook zoiets moet hebben. De windows experts zullen dat wel kunnen uitlichten :)
Snel iets kunnen opzoeken is iets anders dan een bestandssysteem dat je data automatisch verdeelt over de beschikbare fysieke media.

Als je dus /mnt/Films hebt en je disk is vol hoef je geen /mnt/Films2 te maken als je een extra disk in je systeem hangt, maar heeft je /mnt/Films vanzelf extra vrije ruimte. Technisch gezien niet makkelijk in te bouwen, maar voor de gebruiker wel heel makkelijk. De gemiddelde gebruiker zal het echt niet boeien op welke van de 4 schijven een filmpje staat als hij hem maar kan terugvinden.
Dat is er niet. Op linux heb je MDADM, LVM en ZFS dus ook (en nog wel wat, maar ik denk, laat ik even wat makkelijk google-bare afkortingen nemen). Allemaal stuk voor stuk te configureren om precies dat te doen. Op windows kan dat niet, om dat het systeem nou eenmaal niet zo bedoeld of gebouwd is.
Kortom, een beetje de indexing feature van NTFS5, en de Libary functie van W7 dus? De ingeboude redundantie bij NTFS weet ik niet zoveel van af, maar het is inmiddels al wel een tijd journalling, wat suggereerd dat er er wel een soortgelijke feature in zit. Spanning volumes waren ook al een tijd mogelijk.

Om heel eerlijk te zijn zie ik wat dat betreft niet zoveel voordeel boven NTFS (of HFS en Ext4, voordat iemand me weer beschuldigd van voorkeuren), hoewel ik wat meer zou willen weten over de beveiligingen.

Overigens: een 128-bit filesystem? Ooit zal het wel handig zijn, maar voorlopig is 64-bit met een limiet van 16 exbibyte wel voldoende, denk ik (264)

[Reactie gewijzigd door Umbrah op 25 oktober 2009 12:33]

Indexing en libraries hebben er niets mee te maken. Dat gaat alleen maar over makkelijker kunnen vinden waar je de spullen gelaten hebt. Het verandert niets aan de manier waarop het is opgeslagen.

128 bit als overdreven noemen is een beetje een zwaktebod moet ik zeggen. Er zijn prima argumenten om ZFS te bekritiseren (de enorme RAM-honger bijvoorbeeld), maar het gebruiken van 128 bits is daar niet 1 van.
Het unieke van ZFS is dat elk blok data gechecksumd wordt. Voor je data kan je ook zelf kiezen welke checksum je wilt gebruiken (fletcher2 = zwak, maar snel, fletcher4=sterk, maar ietsje langzamer, en sha256 = supersterk, maar traag).

Als je vervolgens een redundant pool hebt (mirror, of raid-z oid), dan zal ZFS bij een checksum mismatch automatisch een blok van een goede bron halen en het beschadigde blok ermee overschrijven, voordat de gebruiker de data krijgt. Self-healing dus.

Een dergelijke beveiliging tegen stille corruptie ben ik nog niet bij andere bestandssystemen tegengekomen die productieklaar zijn.

Dat het hele concept van partities de deur uitgegooid is, is ook prachtig. 1 grote pool van whatever apparaten eronder, en je maakt zoveel filesystems aan als je wilt. Bv je hebt een /data bestandssysteem op de storage pool 'tank'... oh ik wil een /data/gecomprimeerd waarin alle blokken door ZFS gecomprimeerd worden:

zfs create -o compression=on tank/data/gecomprimeerd

En dat is het dan, gemount en al. Oh wacht... op /data/gecomprimeerd/subdir moet de compressie weer uit en een sterkere checksum:

zfs create -o compression=off -o checksum=sha256 tank/data/gecomprimeerd/subdir

en we hebben weer een filesystem :) Op elk filesystem heb je dan evenveel ruimte vrij, namelijk wat er op de complete pool nog vrij is.... nooit meer schipperen met vrije ruimte op meerdere partities.

En dan ben ik nog niet over snapshots en clones begonnen, of over het feit dat je schijven aan je pool kan toevoegen en opeens meer ruimte hebt zonder zelf spullen te resizen o.i.d. :P


Een hoop andere LVM oplossingen zullen ook wel zoiets kunnen, maar ook met een administratieve interface die zo simpel is als bij ZFS?

[Reactie gewijzigd door Sfynx op 26 oktober 2009 04:39]

"16 exbibyte ought to be enough for everyone" ? ;)
Blijkbaar ken je de quote van je favoriete Bill Gates.. ;)

Dat jij graag een gamer bent en om dat je duurdere hardware hebt met een overclock hier en daar en op die manier je jezelf een tweaker noemt mag natuurlijk wel (iedereen is vrij om te doen en laten wat ze willen), maar iemand die echt tweakt wil overal bij kunnen, en met windows kan dat gewoon niet. Je kan niet bij de source, je kan niet een ander FS nemen om te booten, je kan de kernel niet rebuilden om alles weg te laten wat je niet nodig hebt, je kan niet iets anders gebruiken dan dat je door microsoft door je strot geduwd wordt. Zo is het, face it. Als je er blij en gelukkig mee bent is dat leuk, maar mensen die meer opslagbehoefte hebben (en dat worden er steeds meer, alleen laatste week al heb ik meer dan 20 keer een 10+TiB dataserver voor persoonlijk/huishoudelijk gebruik geleverd) en voor die mensen is/was ZFS een prachtige ontwikkeling. En ja, als je dan BSD of Linux gebruikt en lekker met Samba als DC een windows netwerkje van snelle bestandsopslag kan voorzien, dan is iedereen blij. Daar kan echt geen Windows NTFS version 99 met superfetchindexlibrarydatabase spul tegen op.

btw, het is geen flame, gewoon een ander perspectief :)

[Reactie gewijzigd door johnkeates op 25 oktober 2009 14:17]

Blijkbaar ken je de quote van je favoriete Bill Gates.. ;)
Die helemaal niet van Gates is, maar van iemand bij IBM, IIRC.
wie was er eerder
ZFS of Windows 7?
:)
Met NTFS kan je volumes gewoon in folder mounten, het is zelfs mogenlijk om removable media in een folder te mounten. De enig driveletter die je nodig hebt is C: voor je windows-install, de rest zet je gewoon in C:\media, C:\floppy, C:\DVD, C:\download, enz.
Bij zfs heb je pools en daar kan je meerdere file systems onder zetten. de capaciteit van de pool word verdeeld over alle file systems. dat betekend dus dat wanneer of media of floppy of dvd of download vol zit alle capaciteit gebruikt is.

Bij de oplossing die jij geeft kan het zijn dat wanneer je 4 x 500gb schijven hebt en een aan media koppelt en deze vol is je nog wel 100-en gb's over hebt onder floppy en DVD en download die onbenut worden. (ook alle 1 schijf gekoppeld.

Bij ZFS zitten alle 4 de schijven in de pool en kan je dus 2 TB verdelen hoe je dat ook maar wilt. (bv 1.8TB media 0.001TB floppy 0.01 DVD en 0.099 download.

Je kan dus gewoon schijven er bij zetten en je capaciteit vergroten zonder dat je allerlei bestanden heen en weer hoeft te kopieren.
Dat verandert het argument niet... je moet nu alleen in C:\media1, C:\media2, C:\media3 zoeken ipv D: E: en F:.
Een tweaker wil een super optimaal systeem, daar past ZFS goed in. Wat jij beschrijft is meer een gamer en echt totaal geen tweaker, ik wil wel een FS verspreid over meerdere computers gelinkt via de cloud als het mogelijk was.

edit: en als tweaker wil ik niet gewoon windows en wat games, ik wil een massive multiboot systeem zodat ik met BSD/Linux/Windows/Osx86 kan spelen.

[Reactie gewijzigd door teek2 op 25 oktober 2009 12:47]

Lekker kort door de bocht. Wil de tweaker echt alleen maar Windows + een paar games? Er zullen ongetwijfeld een hoop mensen zijn die hun computer zo gebruiken, maar er zijn er ook genoeg die op een hele andere manier met hun computer omgaan. Zijn die dan geen tweaker?

Als ik een FS kan gebruiken dat effectiever en vooral veiliger kan werken met mijn data, dan ben ik zeker geďnteresseerd. Windows.. games.. ? Niet aan mij besteed.
Mijn gok is dat Apple zich realiseert dat over en paar jaar alle computers die ze verkopen SSD's hebben en de huidige bestandssystemen zijn daar geen van alle voor geoptimaliseerd. ZFS is ook vooral ontwikkeld voor gebruik van meerdere harde schijven. Als je toch wat nieuws gaat maken dan kun je beter iets kiezen wat ook geoptimaliseerd is voor de laptops die je (gaat) verkopen die geen harde schijven meer hebben.
ZFS is ontwikkeld om beide te gebruiken. Harde schijven (Spinning rust) geven namelijk op dit moment absoluut de beste bang-for-the-buck: de prijs per gigabyte is enorm laag. SSD's zijn duurder en kleiner dan HDD's (probeer eens voor een nette prijs een 2TB SSD te vinden), maar veel en veel sneller.

Gegeven dat, kan ZFS daar wat mee doen. Een gemiddeld FS heeft twee 'laagjes' waar data vandaan kan komen: spinning rust, en het geheugen van de computer die er wat mee doet (filesystem cache). ZFS propt er een laagje tussen: een L2ARC (Level 2 Adaptive Replacement Cache), een tweede laagje van de ARC (dat is wat ZFS de filesystem cache in het geheugen noemt.) Die functioneert op een soortgelijke manier: files die veel geaccessed worden, worden in de eerste instantie in het geheugen gepropt. Maar als dat vol zit moet je naar disk en dat is traag. De L2ARC stelt je in staat om een tweede laagje te gebruiken als cache die langzamer is dan het geheugen maar nog altijd een boel sneller dan je disk.

Als je een drukke ftp server hebt o.i.d. waar veel clients aan dezelfde set grote files staan te lurken kan zoiets bijzonder nuttig zijn voor de performance, terwijl je toch de goedkope bulk storage van disks hebt.
Oke, ik begreep al niet helemaal waarom Apple met zfs bezig was. Nu moet ik je zeggen dat ik het absolute voordeel tegenover HSF+ er nog niet meteen van inzie, want volgens mij is HSF+ ook 'goed schaalbaar'.

Wat zfs toevoegt aan databeveiliging weet ik niet, dus daar kan ik geen uitspraak over doen,
Nou, die databeveiling was dan ook precies het mooiste element.

Zie het een beetje als .par voor je partitie.

Waar raid beschermt tegen het uitvallen van een hele hardschijf, beschermt ZFS tegen kapotte sectoren. Iets waar eignelijk geen enkele oplossing voor is.

Met ZFS aan, kan je harde schijf slechte sectoren krijgen ZONDER data verlies.
Zo'n extra stukje pariteit voor foutcorrectie is zeer mooi. Echter, hadden de meeste hardeschijven niet zelf ook al een foutcorrectie?
(die is volledig onzichtbaar naar buiten toe overigens; je denkt 8 bits te lezen maar de hardeschijf leest er intern eigenlijk 10)
De data integriteitscontrole in ZFS zit van de onderlagen in harddisken tot vrij aan het gebruik in je geheugen door de applicaties. ZFS zelf kan dus in je log file beschrijven waar het misgaat, in de harddisk, je RAID controller, je geheugen, je processor (en zijn registers). Dat gaat best ver.

Verder heeft ZFS de mogelijkheid om ook compressie in het file systeem aan te bieden en kan je dynamisch harddisken aan een storage pool toevoegen en verwijderen. Dat lukt je alleen met een Drobo. :) Alleen ZFS heeft het dus bedoelt te implementeren voor als je vele terabytes te beheren hebt.

Ook maakt het nog eens pittig gebruik van je CPU, geheugen, eventuele SSD's, RAID controllers en tape backend.

Ik denk trouwens dat het vooral om willen van de restrictieve licentie van Sun niets geworden is met Apple. Ik vind het erg jammer. Ik gebruik ZFS op een BSD en dat is best leuk werken. Helaas is er nergens anders native ZFS te vinden in kernel-space dan op OpenSolaris en de BSD's. Voor op mijn werk is dat dus helaas geen optie. In userspace (zelf ook wel eens mee gespeeld door het zelf te builden van source) is het toch een aardig stukje trager.
Vergeet als optie ook niet de hybrid storage pools, je kunt daarmee een array met grote / goedkope schijven neerzetten als opslag met zowel aan de read als aan de write kant SSD's welke gebruikt worden als caching mechanisme... Hiermee kun je met veel goedkopere storage hoge snelheden bereiken. NexentaStor gebruikt dit in hun NAS/SAN appliance software. Het lijkt een beetje op wat adaptec in hun nieuwe controllers als addon heeft.

Wat verder nog erg nuttig is aan ZFS is dat het tevens block volumes kan managen, het is dus zeer geschikt achter een iscsi target implementatie.
Dat klinkt inderdaad als een interessante toepassing. Dan nog snap ik wel waarom ze ermee stoppen (in navolging van de laatste alinea van het nieuwsbericht).

Als zfs inderdaad zo'n fantastisch idee is, komt er vast wel een ander die ermee doorgaat.
Als zfs inderdaad zo'n fantastisch idee is, komt er vast wel een ander die ermee doorgaat.
FreeBSD 8.0 heeft inmiddels een erg stabiele ZFS release ingebakken zitten, ik ga ervan uit dat die club gewoon fijn doorgaat met hun ZFS port als de anderen ermee zouden stoppen. Of zou dat ook juridisch problemen gaan geven?

Heerlijk bestandssysteem... vooral de data-integriteit, ingebouwde compressie, gebrek aan partities, zoveel filesystems als je wilt met de settings die je wilt, en de snapshots waardeer ik erg. Het werkt ook allemaal heel intuďtief qua administratie met de zpool en zfs commando's.

Ik heb de manier waarop ik lokale backups maak enorm kunnen versimpelen en versnellen door gebruik te maken van de snapshot-functie, en kan zelfs data-integriteits functies in de database server uitzetten omdat het onderliggende filesystem dat al voor me doet :)

[Reactie gewijzigd door Sfynx op 26 oktober 2009 04:11]

Ik heb mijn god geen idee hoe ik moet modden, maar dit vind ik een puike reactie! ;) tnx!
Apple is volgens mij al langer bezig een databasegedreven bestandsysteem te zoeken voor OSX.
De programma's zijn hier al op voorbereid, iPhoto, iTunes, Finder, etc. Als er een echt database gedreven filesysteem zou komen dan zou dat allemaal razend snel werken, daarnaast maakt het onder OSX niet echt wat uit wáár je bestanden staan, vooral dat je ze makkelijk en snel kan vinden.
Volgens mij is er op dit moment nog niet echt een goede optie beschikbaar, eigenlijk alle uitontwikkelde systemen zijn hiarchische filesystems. ZFS ging een heel klein beetje die kant op.
Oracle en MS ook al. Van Oracle weet ik dat ze het al hebben, maar het is een beetje t r a a a a a a g . . . MS en Apple kampen met hetzelfde probleem. Aangezien ze zelfs bij db specialist Oracle het nootje nog steeds niet gekraakt hebben, denk ik dat ook Apple en MS nog wel even bezig zijn met een db-geöriënteerd filesysteem dat net zo goed en snel werkt als wat we gewend zijn.
Oracle heeft nu hun DBFS (database file system), wat ze gebruiken voor data loading in hun oracle database machine.
Volgens de cijfers zou ik dit niet als traag beschouwen.

Meer info op: http://kevinclosson.wordp...tarts-with-transfer-time/
Staat hfs+ het ook toe dat je 1 fs over meerdere schijven maakt en dus geen raid nodig hebt?
Nu weet ik niet zo veel van osx af dus misschien heb ik het helemaal verkeerd. Maar heeft osx niet zoiets aanboord als EVMS of LVM(2) waarmee je zo'n soort setup zou kunnen bereiken? En al zou het niet zo zijn, apple volgt toch ook de FHS dus zou het in principe ook niet zo heel erg nodig moeten zijn op desktop systemen?

maar goed, zoals ik al zei: ik heb geen verstand van osx en ik zou graag een reactie van iemand willen zien waarom ZFS een grote toegevoegde waarde is (helemaal op server platformen) omdat ik er veel over hoor, maar nooit iets inhoudelijks.
Op http://www.sun.com/lawsuit/zfs/ is de voortgang te lezen over de claims van Netapp tegen Sun en waar het precies over gaat (Copy-on-Write en snapshots).

Jammer dat ZFS nu helemaal geschrapt is, maar dat was wel te verwachten. Wat ook belangrijk is voor Apple is dat ze met ZFS wel een stabiel filesystem krijgen, maar dat de vraag is of het wel bestand is tegen "misbruik" door reguliere gebruikers.

Corruptie van je pool wil je niet en volgens mij liggen daar nog wat risico's als de kabel van je externe USB HDD met Timemachine backups opeens los gaat o.i.d.
Natuurlijk hoef je je externe schijven niet te voorzien van ZFS, maar op desktop gebied moet er volgens mij nog veel getest worden.
ZFS heeft juist als redelijk unieke feature dat de toestand op disk altijd consistent is. Lijkt op journaling, maar dan beter. De zfs driver in Leopard geeft inderdaad een kernel panic als je een schijf unplugt zonder te exporteren (equivalent van unmounten).

Als de harde schijf in je mac zfs is, en je Time Machine schijf ook, kun je enorm efficient en makkelijk je backups draaien. Zie http://webcast-west.sun.com/interactive/09B12437/index.html voor hoe het geintegreerd is in Gnome in opensolaris.
Ongetwijfeld, maar fatsoenlijke recovery tools ontbreken. En een kernel panic als zoiets gebeurt, spreekt nou niet in het voordeel van ZFS.

Recovery tools zijn gepland voor Q4, maar nog niet gerealiseerd als ik wikipedia moet geloven.

Maar Timemachine zou zeker voordeel hebben van ZFS, dat geloof ik meteen.
Ongetwijfeld, maar fatsoenlijke recovery tools ontbreken. En een kernel panic als zoiets gebeurt, spreekt nou niet in het voordeel van ZFS.
Vergeet even niet dat dat specifiek is aan de Darwin port he. Solaris geeft geen kik als je een willekeurige schijf eruit rukt. Pas als er I/O naar die schijf moet merkt 'ie: 'ho eens even', en gaat de schijf offline.
als de rechtszaken voorbij zijn, zal apple de eerste zijn om het officieel uit te brengen.
het is nu al productie kwaliteit, het probleem ligt hem inderdaad in de patenten.

ze hebben er aardig wat tijd in geďnvesteerd, dus het is niet volledig afgeschreven.

[Reactie gewijzigd door stewie op 26 oktober 2009 18:09]

Corruptie van je pool wil je niet en volgens mij liggen daar nog wat risico's als de kabel van je externe USB HDD met Timemachine backups opeens los gaat o.i.d.
Zolang die USB schijf het "zet nu alles in je cache op de platters" a.k.a write cache flush commando honoreert, zal een ZFS pool op die schijf niet corrupt raken doordat het volume plotseling weg is, omdat alle veranderingen bij ZFS transactioneel worden doorgevoerd.

Of een transactie staat wel in de ZFS Intent Log (ZIL, soort van transactionele journal) en wordt na rebooten alsnog doorgevoerd (replay) of de transactie komt nooit bij de pool aan. Als iets daar tussenin mogelijk is, is dat een bug in ZFS.

[Reactie gewijzigd door Sfynx op 26 oktober 2009 04:55]

Ik las dat Btrfs een goed ZFS alternatief is, heeft iemand er verstand van, mag Apple wel een gpl FS gewoon gebruiken in zijn kernel?

Edit: http://en.wikipedia.org/wiki/Btrfs :
Nog niet production ready helaas, maar goed, in principe is het mogelijk.

[Reactie gewijzigd door teek2 op 25 oktober 2009 12:16]

Mac OS X's kernel (darwin) is gewoon open source hoor, volgens mij onder de BSD license.

http://www.opensource.apple.com/

Zo maakt XCode (development omgeving voor OS X/iPhone) gewoon gebruik van GCC.
Wat je stelt is juist, echter er gelden andere voorwaarden bij het gebruik van executables dan het gebruik van code, waardoor je zo'n filesysteem niet zomaar in je kernel kan integreren.

Als je GPL code gebruikt als 'bouwsteen' dan geldt dat je product afgeleid is van de GPL code: jouw code moet dan ook GPL worden. Wanneer je echter een executable aanroept waarvan de code GPL is dan hoeft dat niet en dat is wat XCode doet. Apple heeft ook een eigen build van GCC waar vast het een en ander aan is toegevoegd, die code die ze toevoegen moeten ze onder GPL vrijgeven en niet BSD.
Als ze aanpassingen hadden gemaakt aan GCC, dan waren ze al lang aangesproken geweest door die tent waarbij je dat kan melden. (diezelfde die pas op het punt stond achter HTC aan te gaan vanwege die Hero kernel sources).

Ze hebben wel een eigen build, maar die is gewoon door hun gemaakt voor Mac OS X. (wel zo handig). Hoef je 't zelf niet meer te doen.

Daarnaast kunnen ze eventuele aanpassingen ook in plugins hebben gestopt, dan passen ze GCC niet aan, en laden alleen een plugin/module. ( bijvoorbeeld van het outputen van universal binaries)
mag Apple wel een gpl FS gewoon gebruiken in zijn kernel?
Ja mits de Apple kernel ook GPL is/wordt.

Momenteel is de license die Apple hanteert (voor de kernel) niet GPL compatibel.
http://www.mail-archive.com/kaffe@kaffe.org/msg12686.html
Ja mits de Apple kernel ook GPL is/wordt.
Nee hoor, de eigenaar van GPL code kan ook besluiten apple een andere licentie te gunnen. (bijvoorbeeld BSD of propietary).

Daarnaast kunnen ze de implementatie gewoon zelfgeschreven hebben, en dus komt er geen GPL code aan te pas.

Bovendien kun je Solaris volgens mij onder 2 licenties krijgen, de GPL, en een andere.
Nee hoor, de eigenaar van GPL code kan ook besluiten apple een andere licentie te gunnen. (bijvoorbeeld BSD of propietary).
Klopt, maar dan zal de eigenaar overgehaalt moeten worden om de code als dual license vrij te geven.
Als je meerder contributers had zal het moeilijk worden omdat het allemaal copyright eigenaars zijn voor hun deel van de code. Ze moeten het allemaal eens zijn met de license verandering.
Daarnaast kunnen ze de implementatie gewoon zelfgeschreven hebben, en dus komt er geen GPL code aan te pas.
Het gaat hier over brfs dit bestaande GPL code (van Oracle). Dus niet zelf geschreven door Apple.
Alleen als je voortbouwt op de 'GPL' code moet je het toch vrijlaten?

Immers een applicatie die op de kernel draait hoeven ze ook niet vrij te geven, en de bestandssysteem val niet zo zeer direct onder de kernel. (Immers kan je die gewoon vervangen voor een andere).
Daarnaast kunnen ze de implementatie gewoon zelfgeschreven hebben, en dus komt er geen GPL code aan te pas.
Het ging hier over btrfs dit een deel van de kernel dat onder GPL vrijgegeven is. Als je dit in de kernel integreert wordt dan moet deze ook GPL worden. Dit is namelijk geen applicatie.
In principe valt een idee of een formaat niet onder GPL. Een software-implementatie kan daar echter wel onder vallen.
Als Apple zelf de code schrijft die precies doet wat de specificaties van een filesysteem beschrijft, dan valt dat niet onder GPL, tenzij Apple dat natuurlijk uitgeeft onder GPL.
Als iemand anders onder GPL uitgegeven code gebruikt, dan moeten eventueel gemaakte aanpassingen vrijgegeven worden en de licentie meegeleverd worden.

Zo heeft mijn TV bijvoorbeeld een optie in het menu om de GPL weer te geven, maar de sourcecode van de hele firmware van dat toestel hoeft Panasonic echt niet te geven.
Dus ja, je mag GPL-software in commerciele toepassingen gebruiken, maar de vraag is wel of je aan alle eisen voldoet en dat kan het soms lastig maken.

IMHO is het positief wanneer belangrijke OS-en open filesystems zouden ondersteunen, omdat dat de onderlinge uitwisseling alleen maar ten goede komt.
al is btrFS meer voor SSD`s
En voor enorme filesystems over meerdere devices (disks in een computer) en wellicht ooit over meerdere systemen (meerdere computers).
brtfs is dus echt geen distributed filesystem...
brtfs is niet specifiek voor ssd's...al wordt er in de implementatie wel rekening mee gehouden.
Oracle heeft al aangegeven MySQL niet verder vrij te geven. En is dus van plan My SQL niet verder te ontwikkelen ter bevoordeling van de Oracle database.... Of ze zullen geld gaan vragen voor MySQL.

ZFS zal een zelfde behandeling krijgen is de verwachting. Oracle is altijd een kostbare klub geweest. Dit zal ongetwijfeld een duw geven aan de opensource ontwikkeling. Of .... Dat zal stilvallen en zachtjes aan zal iedereen de licentiegelden meenemen in zijn haar product.

We wachten af.

Neelie Smith Kroes is het niet eens met het samengaan van Sun en Oracle (Oracle heeft het noodlijdende Sun aangekocht in de USA.). Ook dit zal van invloed zijn op toekomstige ontwikkelingen.
Oracle heeft al aangegeven MySQL niet verder vrij te geven.
Kun je hier het linkje van geven?

Ik kon alleen deze link vinden.
nieuws: Oracle gaat Suns MySQL niet afstoten
ZFS zal een zelfde behandeling krijgen is de verwachting. Oracle is altijd een kostbare klub geweest. Dit zal ongetwijfeld een duw geven aan de opensource ontwikkeling. Of .... Dat zal stilvallen en zachtjes aan zal iedereen de licentiegelden meenemen in zijn haar product.
Oracle doet meer binnen OSS dan je denkt. Ze hebben zelf het OCFS2 filesystem dat GPL is.

Mogelijk is Apple bang dat ZFS ook GPL gaat worden. Dan kunnen ze met hun huidige kernel license niet meer meeliften op de nieuwe ontwikkelingen.

[Reactie gewijzigd door worldcitizen op 25 oktober 2009 13:04]

Oracle heeft al aangegeven MySQL niet verder vrij te geven.
dat hebben ze dus nergens, er zijn mensen die met de hele zaak niets te maken hebben die het te pas en te onpas overal in comments bij blog posts schrijven. Er is In pers berichten en uit de mond van de ceo zelf duidelijk gezegd dat dit niet het plan is. Als ze op eens 180 graden draaien dan hebben ze de aandeelhouders misleid. Wat mij onwaarschijnlijk lijkt.
ZFS zal een zelfde behandeling krijgen is de verwachting.
dit hoor ik nu helemaal voor het eerst en is erg onwaarschijnlijk gezien opensolaris boot onder ZFS en omdat werkzaamheden aan ZFS ook onder opensolaris vallen. Als ZFS de 'zelfde behandeling' krijgt dan geeft dat ernome problemen voor opensolaris. Niemand schiet daar iets mee op.
Mogelijk is Apple bang dat ZFS ook GPL gaat worden. Dan kunnen ze met hun huidige kernel license niet meer meeliften op de nieuwe ontwikkelingen.
Dan zou dat hooguit een GPL/CDDL dual licentie worden. En ook daarbij trek je een bak met problemen open. Deze discussie is lang gevoerd nadat CDDL licentie bekend was gemaakt.

@worldcitizen
Sun heeft officieel niet echt gereageerd volgens mij anders dan aan te wijzen dat CDDL een open source licentie is. Over het alg is er niets tegen gpl licentie anders dan dat die licentie minder vrij is. Omdat CDDL vrijer is word zfs en consorten op plekken gebruikt waar gpl niet handig is. Ongetwijfeld hangen hier contracten etc aan waardoor ook al word het overgenomen Oracle het nog steeds niet zomaar alleen onder de gpl kan uitgeven. Het uitgeven van onder dual lisense GPL/CDDL lost deze problemen op echter dan heb je weer het probleem dat publieke bijdragen hun code ook onder GPL/CDDL moeten aanbieden. Het kan zijn dat er mensen zijn die daar niet op zitten te wachten waar door er een fork komt met het gevolg dat de versies mogelijk uit elkaar groeien. etc.
(gpl is met goede redenen minder vrij / restrictief - dit om vrijheden te beschermen)

[Reactie gewijzigd door Mr_Light op 25 oktober 2009 15:49]

Dan zou dat hooguit een GPL/CDDL dual licentie worden. En ook daarbij trek je een bak met problemen open. Deze discussie is lang gevoerd nadat CDDL licentie bekend was gemaakt.
De discussie is met Sun gevoerd. Binnenkort is Oracle de eigenaar, deze kan heel andere ideeën hebben.

Zo heeft Oracle zelf ook een Linux distro mogelijk zouden ze hier ook ZFS in willen hebben zonder Fusion. Dan zal het GPL moeten worden.
Mogelijk is Apple bang dat ZFS ook GPL gaat worden. Dan kunnen ze met hun huidige kernel license niet meer meeliften op de nieuwe ontwikkelingen.
Onzin, als ze bij Apple code gebruiken die niet GPL is, is er niets aan de hand. Bovendien kun je de specificatie van ZFS niet opeens met terugwerkende kracht GPL'en. Dat zou achterlijk zijn. (en een specificatie kun je sowieso niet echt GPL maken, de sourcecode wel)
Bovendien kun je de specificatie van ZFS niet opeens met terugwerkende kracht GPL'en.
Klopt maar je kunt de licentie van af een bepaalde datum omzetten naar GPL. Dan kan Apple nog steeds met de oude code onder CDDL werken en zelf onderhouden maar geen gebruik meer maken van de nieuwe code als ze zelf niet aan GPL voldoen.

Code veranderen gebeurt wel vaker. Kijk maar naar bijvoorbeeld Xfree86 omdat ze de licentie aangepast hebben ze de laatste code geforked naar xorg.
Dat zou achterlijk zijn. (en een specificatie kun je sowieso niet echt GPL maken, de sourcecode wel)
Volgens mij gebruikte Apple de source code die door Sun geschreven is niet allen de spec.
Maar ja, wat heeft Neeltje te maken met het wel of niet samen gaan van 2 Amerikaanse bedrijven? Als de Amerikaanse monopoly waakhond (kan ff niet op de naam komen) het oke vind heeft Neeltje volgens mij weinig te vertellen... ze kan volgens mij hooguit zeggen dat ze het er niet mee eens is.
Nee, ze kan hoogstens zeggen dat Sun en Oracle niet meer in Europa mogen verkopen.
Of eisen dat een deel verkocht moet worden voordat ze in Europa zaken mogen doen.
Als dat zo is, mag je mij uitleggen hoe "Neeltje" het voor elkaar krijgt dat Microsoft, ook een Amerikaans bedrijf, naar haar pijpen danst.

Het antwoord kan ik je alvast verklappen: Deze bedrijven overstijgen de Amerikaanse markt: Hun produkten zijn ook in Europa beschikbaar.
Als ik het goed begrijp is ZFS voornamelijk interessant als je veel harddisken hebt of in ieder geval meer dan 1. Afaik verkoopt apple voornamelijk laptop computers waar dus maar 1 harddisk in zit. Kan me daarom voorstellen dat dit nooit een hoge prioriteit heeft gehad en het alleen ge-beta test is in Server.
Afaik verkoopt apple voornamelijk laptop computers waar dus maar 1 harddisk in zit.
Voor met name hun x-serves (waarvan ik toevallig weet dat er echt wel wat verkocht worden) en Mac Pro's is het best intressant, los van het feit dat het ook voor single-disk een prima keuze is.

Zie het als 'journaling' maar dan nog beter.
Als ik het goed begrijp is ZFS voornamelijk interessant als je veel harddisken hebt of in ieder geval meer dan 1. Afaik verkoopt apple voornamelijk laptop computers waar dus maar 1 harddisk in zit. Kan me daarom voorstellen dat dit nooit een hoge prioriteit heeft gehad en het alleen ge-beta test is in Server.
Dat begrijp je verkeerd. ZFS heeft ook heel veel features die nuttig zijn als je maar 1 drive hebt.
externe drives mischien?
Weer een voorbeeld van hoe patenten de ontwikkeling schade toebrengen.
Bedrijven worden overgenomen alleen om zo patenten in bezit te krijgen om dan later de investering weer teug te verdienen door rechtszaken aan te spannen.
Weer een voorbeeld van hoe patenten de ontwikkeling schade toebrengen.
Bedrijven worden overgenomen alleen om zo patenten in bezit te krijgen om dan later de investering weer teug te verdienen door rechtszaken aan te spannen.
Heb jij enig idee wie NetApp is? Dat is echt geen toko die door wat overnames wat patenten in handen gekregen heeft, en nu wil gaan graaien. NetApp is al langer dan ik me kan herinneren in de high-end storage markt.
Er was zelfs aangekondigd dat ZFS bij Snow Leopard Server zou worden geleverd. Dat was dus niet zo.

Een goede post op Storagemojo hierover: http://storagemojo.com/2009/08/31/why-did-apple-drop-zfs/
Als het open--source is, mogen ze dan zomaar de informatie erover offline halen?
Heeft iemand kopieën voor andere gebruikers met innterresse?

Misschien iets voor Goggle Summer of code 2010? ;-)
Tuurlijk mogen ze de informatie erover offline halen.. Zolang ze nog geen product op de markt hebben gebracht waar ze hun aanpassingen in gebruiken, hoeven ze zelfs niet de sourcecode te publiceren..

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True