Google stapt over op ext4-bestandssysteem

Google is begonnen om zijn opslagsystemen te upgraden van het ext2-bestandssysteem naar ext4. Het bedrijf heeft om de klus te klaren een van de hoofdontwikkelaars van het relatief nieuwe filesystem ingehuurd.

Theodore Ts'o, een bekende Linux kernel-ontwikkelaar en lange tijd werkzaam bij IBM, is vertrokken uit de Linux Foundation om bij Google aan de slag te gaan, zo meldt Ars Technica. Hij zal de migratie van de opslaginfrastructuur van Google van ext2 naar ext4 in goede banen moeten leiden, zo meldt hij op zijn weblog. Ondanks zijn nieuwe functie bij Google belooft Ts'o wel te blijven werken aan de doorontwikkeling van het ext4-bestandssysteem en andere kernelprojecten.

Hoofdreden voor de migratie binnen Google naar ext4 zou zijn dat harde schijven die volgens het ext2-bestandssysteem zijn ingedeeld, onvoldoende prestaties zouden leveren door een verschijnsel dat een Google-ontwikkelaar Micheael Rubin onlangs beschreef als read inflation. Op ext2-bestandssystemen zou de opgeslagen informatie op termijn door een weinig efficiënte blokindeling zo versnipperd raken, dat de toegangstijden steeds hoger werden.

Volgens Rubin heeft Google twee bestandssystemen nader bekeken die het probleem zouden moeten oplossen: xfs en ext4. De laatste kwam uiteindelijk als winnaar uit de bus; ext4 zou aanmerkelijk beter presteren dan ext2 en de snelheden benaderen van het xfs-file system. De doorslag in de keuze voor ext4 was dat Google zijn bestaande ext2-schijven met relatief weinig moeite in een draaiende omgeving naar ext4 zou kunnen overzetten.

De overstap van Google naar ext4 is opnieuw een bevestiging dat het relatief nieuwe bestandssysteem als volwassen wordt beschouwd. Ext4 biedt ten opzichte van ext3- en ext2-bestandssystemen verbeterde prestaties en een efficiëntere indeling. Tijdens de ontwikkeling kreeg ext4 nog de kritiek dat het delayed allocation-mechanisme tot dataverlies zou kunnen leiden, maar Ts'o wist met een aantal patches dit probleem te verhelpen. Inmiddels zijn vrijwel alle grote Linux-distributies overgestapt naar het bestandssysteem.

Reacties (106)

[Pixeltje]

Handig dat je je omgeving in de lucht kunt houden tijdens het overstappen naar ext4, maar wat is nu het voordeel van ext4 tegenover NTFS of bijvoorbeeld HFS?

Eerlijk gezegd had ik niet verwacht dat Google ext3 had overgeslagen, omdat dat bestandssysteem ook al een flinke verbetering was ten opzichte van ext2.

[_JGC_]

Als je hele serverpark op linux draait zijn NTFS en HFS(+) geen logische keuzes. Je zit dan gewoon vast aan ext2/3/4, reiserfs, JFS, XFS en het nieuwe btrfs.
Btrfs is geen logische keuze, dat FS staat nog in de kinderschoenen. De auteur van Reiserfs is opgesloten en voor zover ik weet zit reiser4 nog steeds niet in de kernel, dus die vallen ook gewoon af.
JFS heb ik te weinig ervaring mee om iets over te zeggen. XFS heb ik wel ervaring mee, is een super filesystem zolang alles goed gaat. Op het moment dat het stuk gaat is het een hel om te herstellen, aangezien je filesystem niet gekoppeld mag zijn tijdens een controle. Het zal maar net je rootfs zijn, mag je booten met rescue media om je rootfs na te kunnen kijken. Ext2,3,4 hebben dit nadeel niet en kunnen gewoon gecontroleerd en hersteld worden zolang ze readonly gekoppeld zijn. Dat laatste nadeel heeft mij ertoe aangezet om al mijn servers opnieuw te formatteren met ext3.

[Xeon_vl]

XFS als root is zowiezo moeilijk aangezien LILO nergens nog wordt gebruikt omdat het te oud is (denk ik toch) en grub geen XFS root partitie kan booten (misschien in de laatste versies wel maar wat je in distributies aantreft kan het niet), en verder weet ik zo niet direct iets.

[_JGC_]

Grub kan gewoon met XFS overweg, als het goed is zou je in /boot/grub een stage_1_5 loader voor XFS moeten vinden. Lilo wordt overigens nog steeds wel gebruikt, vooral bij GPT disklabels die niet door Grub ondersteund worden (er zijn patches en Grub2 zou het wel moeten doen).

[Dim]

Grub kan prima booten van XFS, zeker als je enigszins recente Linux distro's gebruikt. Ik beheer verschillende servers die XFS gebruiken voor al hun filesystems, en er zijn nooit problemen mee. XFS is snel en stabiel, niks mis mee, IMHO.

[cashewnut]

XFS moet je m.i. ook niet als root filesystem willen. Het is speciaal bedoeld voor het opslaan van grote bestanden. Dan presteert het echt goed. Dus muziek, films, dat soort dingen. Niet de honderden kleine executables, libraries, logfiles, configfiles etc die je vaak op een root filesystem aantreft. Dan is een ext* filesystem een betere keuze.

[Munters]

Duidelijk, maar waarom dan ext3 en niet ext4?

[ppl]

Waarschijnlijk omdat ext4 toen nog niet bestond (lees: vrijgegeven was) of omdat hij de eerder genoemde dataloss problemen van ext4 niet acceptabel vond. In geval van Google is dat niet erg omdat ze heel wat redundancy hebben, daar maakt het niet uit of een server uitvalt omdat ze hun systeem daarop hebben ingericht. Bij wat kleinere bedrijven en thiusgebruikers is dat een heel ander verhaal. Daar is vaak maar 1 server aanwezig en geen budget om de boel dermate redundant te maken dat dataloss geen probleem is. In die gevallen is ext3 een wat betere keuze.

[Pixeltje]

Oke, weer wat geleerd. 'Tis dat ik je geen +2 kan geven (reactie op mijn reactie) maar bedankt!

[elleP]

Volgens mij wilde google niet aan ext3 omdat dat tov ext2 meer schrijfacties heeft, wat met name voor flash opslag op lange termijn schadelijk is.

[borft]

ext4 heeft ook journaling, dus dat zal het niet zijn

[webkiller71]

Google heeft patches aangeleverd om ext4 zonder journaling te gebruiken. Zie http://kernelnewbies.org/...a0c184889b5f00764cb9beb1e voor meer info.

[Olaf van der Spek]

Handig dat je je omgeving in de lucht kunt houden tijdens het overstappen naar ext4, maar wat is nu het voordeel van ext4 tegenover NTFS of bijvoorbeeld HFS?

In ieder geval de licentie. En NTFS is niet open (source).
De reden waarom Google overstapt is ook meer de block allocator, niet zozeer het on-disk gedeelte van het FS.

[page404]

volgens mij is NTFS nu ook niet het best performende bestandssysteem ter wereld. dat het niet heel nieuw meer is (eind jaren 80 of zo?) speelt ook mee wellicht

[Xthemes.us]

Denk niet dat je het NTFS van toen moet vergelijken met dat van nu. Dat was versie 1, daarna zijn 1.1, 1.2, 3.0 en 3.1 uitgebracht.

Maar goed, lijkt me zeer sterk dat google geinteresseerd zou zijn in NTFS gezien ze dan met Microsoft in overleg moeten en het totaal geen voordeel bied boven wat er door de opensource community word aangeboden. Grootste voordeel zoals in het artikel staat zal liggen in dat het erg makkelijk is om van ext2 naar 4 te gaan.

[Verwijderd]

Waarom gaan ze niet meteen aan de BTRFS, zie http://en.wikipedia.org/wiki/Btrfs? Dit is de meest voor de hand liggende opvolger.

Zie ook de benchmarks:

http://www.phoronix.com/s...m=ext4_btrfs_nilfs2&num=2

[Edit] Omdat dat performance van ext4 nog beter is op sommige vlakken dus

[Reactie gewijzigd door Verwijderd op 23 juli 2024 06:00]

[merlijn85]

Een belangrijke reden voor Google om te kiezen voor ext4, is de modulaire opbouw. Alles features kunnen aan of uit gezet worden en daar hecht Google grote waarde aan.

De oplettende lezer zal zich afvragen waarom Google nog ext2 draaide en nooit is overgegaan op ext3, en het antwoord is dat ext3 verplicht journalling heeft. Bij Google geloven ze niet zo in journals, omdat dit ten koste gaat van de performance, dit is o.a. de reden dat Google patches heeft verzorgd voor ext4 zodat een ext2 FS gemount kan worden met de code van ext4. Door deze patches hebben ze al een hele tijd de voordelen van delayed allocation, terwijl de onderlaag nog het platte ext2 is.

Waarschijnlijk willen ze nu overstappen op ext4 vanwege de voordelen die de nieuwe inode structuur heeft (niet meer de indirect block headers in de inode table). Dit lost voor een groot deel het 'read inflation' probleem op.

[trogdor]

Heb jij wel eens een ext2 filesystem naar een btrfs filesystem gemigreerd ?
Hoe eenvoudig is dat, hoeveel extra ruimte is er voor nodig, wat is de verwachte performance winst, hoe stabiel is het, is het opensource ?
Als je geen antwoord hebt op deze vragen dan is je post vrij zinloos.
Waarom niet filesystem [vul hier je favoriete fs in]. Nou, omdat ext4 het beste en eenvoudigste wordt bevonden, dat staat ook in het artikel.

[Verwijderd]

Nee, maar over het algemeen is een migratie niet zo heel moeilijk, zolang je het niet in-place doet.

Ik zie niet terug in het originele artikel dat Google naar btrfs heeft gegeken, en waarom het niet mee is genomen.

Als ik het een nieuw filesysteem zou moeten overwegen, zou ik jouw vragen dan ook echt wel gaan uitzoeken, en btrfs mee hebben genomen. En dan nog zouden mijn ervaringen niks zeggen over hoe het Google zou bevallen, simpelweg omdat ik ervan uitga dat Google niet precies dezelfde criteria en requirements heeft als ik.

[RitBit]

Denk jij het nu zelf echt beter te weten dan een heel team aan experts ?

Ik weet wel zeker dat ze naar verschillende alternatieven hebben gekeken, ook al staat dat niet in het artikel. Blijkbaar was het migratie-pad minstens zo belangrijk als de perfomance en is de keuze van het Google team op EXT4 gevallen omdat die in totaal aan de meeste eisen voldeed.

[cheeks]

Waarschijnlijk om dat daar nog geen stable release van is (als ik dat artikel mag geloven)

[BackwardsDown]

De doorslag in de keuze voor ext4 was dat Google zijn bestaande ext2-schijven met relatief weinig moeite in een draaiende omgeving naar ext4 zou kunnen overzetten.

[Dim]

Als je even op http://btrfs.wiki.kernel.org/ kijkt, dan staat daar heel prominent op de voorpagina:

Btrfs is under heavy development, and is not suitable for any uses other than benchmarking and review. The Btrfs disk format is not yet finalized, but it will only be changed if a critical bug is found and no workarounds are possible.

Veel duidelijker kan het niet, toch?

[Reactie gewijzigd door Dim op 23 juli 2024 06:00]

[The Realone]

De overstap van Google naar ext4 is opnieuw een bevestiging dat het relatief nieuwe bestandssysteem als volwassen wordt beschouwd.

Mag je dat niet pas stellen als het daadwerkelijk een tijdje probleemloos draait op de Google servers? Nu komt het zo over dat wanneer Google iets gaat gebruiken het meteen volwassen is wat me enigzins vreemd lijkt, hoe goed ze het ook getest mogen hebben.

[hendrickbert]

als je al je servers van een miljarden bedrijf voorziet van ext4 dan verklaar ik het volwassen genoeg voor mijn servertje.

[PolarBear]

Ook miljarden bedrijven kunnen grote fouten maken. Het is niet uitgesloten dat er juist fouten worden gevonden door de grote aantal installaties bij Google.

[Verwijderd]

Ik hoop dat Google de goedheid heeft om de fixes en verbeteringen aan de community terug te schenken. Ze zijn mogelijk de grootste gebruiker van Linux, maar niet terug te vinden in de top 10 van grootste contributors.

[arjankoole]

Ik hoop dat Google de goedheid heeft om de fixes en verbeteringen aan de community terug te schenken. Ze zijn mogelijk de grootste gebruiker van Linux, maar niet terug te vinden in de top 10 van grootste contributors.

Dat je het gebruikt wil nog niet zeggen dat je ook dingen fixed. D'r zijn er genoeg die als basis Linux gebruiken, en daar bovenop een commercieel product draaien. Die zie je ook niet vaak terug in de contrib lijst, puur omdat ze niet echt aanpassingen maken aan het OS. Distributie makers zijn weer wel een partij die daar werken, en daarvan zie je ook veel contribs terugkomen.

[MikeN]

Echter heeft Google de instelling dat ze alles forken in plaats van dat ze patches naar upstream committen. Intern draaien ze volgens mij nog steeds op Linux 2.6.2, omdat ze zo'n zwaar gepatchte installatie hebben dat upgraden bakken werk kost. Om dezelfde reden is Chrome nog steeds niet opgenomen in enkele Linux distributies: er zitten allerlei geforkte libraries in, waarvan de patches gewoon naar upstream gestuurd hadden moeten worden.

[ILUsion]

Waar haal je die statistieken dan vandaan?

Bovendien lijkt het me vreemd om bedrijven te gaan zoeken bij contributors, Google geeft zijn werknemers de vrijheid om tijdens de werkuren te werken aan open-source projecten. Er zullen vast wel mensen aan Linux werken tijdens die uurtjes, maar dat komt in de statistieken onder hun naam te staan en niet onder die van Google.

Wat ik van statistieken kon terugvinden, was weliswaar verouderd (2008/2006), maar daar staat Google toch op 10 (als je Unknown/none als sponsors weglaat, vermits je dat moeilijk bedrijven kan noemen): https://www.linuxfoundati...inuxkerneldevelopment.php

[Goderic]

op de zelfde site een recentere versie: http://www.linuxfoundatio...ations/whowriteslinux.pdf
Google staat op 22 (Unknow/none ook niet meegeteld) met 0.8%

[anboni]

En daarom is het nou juist heel interessant voor de community dat de lead-dev zich met de migratie bezig gaat houden. Hij zit nu lekker dicht op het vuur en kan problemen uitgebreid analyseren.

[ppl]

Ik denk dat je daar wel een cruciale denkfout maakt. Jouw systeem is niet gelijk aan dat van een miljarden bedrijf. Dat miljarden bedrijf heeft namelijk de centen en mogelijkheden om een serverpark van honderden servers neer te zetten en te onderhouden. Het voordeel van honderden servers hebben zit 'm in de redundancy mogelijkheden die je in kunt bouwen. Je kunt het zodanig maken dat als er 10 servers uitvallen je er niets van merkt behalve de melding dat er 10 servers stuk zijn. Als bij jou dat servertje stuk gaat werkt er niets meer. Dat is nogal een gigantisch groot verschil in luxe. Juist daardoor kan Google het zich veroorloven om met minder stabiel state of the art spul te gaan werken en jij niet. Google staat er verder om bekend dat ze hun eigen stuff gebruiken met wat ander state of the art spul. Daarmee is het al bewezen dat er absoluut geen enkel bewijs is dat ext4 volwassen is of als zodanig wordt beschouwd. Wellicht alleen volwassen voor hun eigen gebruik.

[Verwijderd]

Dat lijkt me een onzinnige redenatie. Als een stuk software op 1 server niet goed werkt, dan werkt het op 10, 100, 1000 of 10.000 servers ook niet goed. Dan is het wachten tot het hele serverpark plat ligt. En dan heb je wel een probleem met de mankracht want je hebt niet voor iedere server 1 persoon beschikbaar die de server even opnieuw installeert of de database gaat repareren. Als je een stuk software over een groot aantal machines wilt uitrollen, dan zul je dit echt heel goed moeten testen.

[xentron]

Echter is een filesystem iets anders dan slechts een stuk software. Doordat het een filesystem is en niet een stuk software dat op elke server met gelijke specificaties en software (ongeveer) het zelfde zal reageren, zal een filesystem gewoon zijn werk doen ongeacht de server. Echter zal nu dus niet op elke server de zelfde hoeveelheid schrijf en lees bewerkingen worden gedaan waardoor het dus heel goed mogelijk is dat het ext4 filesystem maar op een paar servers van de 1000 vast kan lopen. Dus uw redenatie dat als het op 1 server vast loopt dat het dan vanzelf sprekend is dat het op alle servers vast gaat lopen (of ik uw woorden "het niet goed doett") is ook een beetje een onrealistische redenatie.

ext4 word nu al een poosje gebruikt in linux distro's en ik kan persoonlijk vrij weinig problemen er meer mee vinden sinds de patches. Dat het nog een nieuwe filesystem is waar we nog niet alle bugjes in geplet hebben klopt, maar het is stabiel genoeg voor gebruik.

[Verwijderd]

Een filesystem is een stuk software. Zonder programmacode die het filesystem implementeerd heb je geen filesystem. Als er bugs in software zitten dan komen die vroeg of laat boven water. De wet van Murphy zegt dat dat altijd op het meest ongelegen moment gebeurt. Ik neem dus aan de Google geen enkel risico neemt en daarom de code goed heeft doorgespit (code review) en uitvoerig getest.

[Mellow Jack]

Snap je het niet of wil je het niet snappen?

Daarom maken ze juist gebruik van redundancy

Het is inderdaad goed mogelijk dat 1 server tegen een bug aan loopt. Wanneer dat bij jou prive gebeurd is dat een ramp maar wanneer dat bij Google gebeurd is dat niet zo'n probleem omdat ze redundant zijn uitgevoerd en de kans dat 1 fout op meerdere servers tegelijk zich voordoet is nihil (omdat dit anders al veel vaker was gebeurd gezien dit FS al veel wordt gebruikt) en daardoor is het voor Google een "gemakkelijke" keuze

[SirBlade]

Dat hangt er vanaf wat google precies met de servers doet en wat jij precies met de servers doet. Volgens het artikel is snelheid de belangrijkste reden geweest voor google's keus. Voor een server die data maar kort bewaard maakt het niet veel uit als er op lange termijn data-corruptie kan optreden. Voor een fileserver heb je liever wat lagere snelheid en meer betrouwbaarheid.

[Olaf van der Spek]

Mag je dat niet pas stellen als het daadwerkelijk een tijdje probleemloos draait op de Google servers?

Nee. Er staat ook 'beschouwd', niet 'is.

[The Realone]

Aangezien er geen keurmerk is voor 'volwassen' zal het altijd een (breedgedragen) mening blijven natuurlijk.

[Verwijderd]

Wat versta jij onder een keurmerk dan?
Volgens mij is dat ook nog altijd een breedgedragen mening, zo breed gedragen zelfs dat hij geformaliseerd is in een zekere norm.....

[The Realone]

Door een officiële keuringsinstantie gegeven keurmerk, certificaat of wat dan ook. Je kent ze wel. Dat is in deze niet echt de discussie, eerder hoe breedgedragen deze "mening" is. Is een enkel bedrijf (hoe groot ook) genoeg?

[MSalters]

Is een "officiele" keuringsinstantie als TNO beter in het beoordelen vann "volwassenheid"? Wat maakt TNO zo bijzonder dat ze Ext4 beter dan Google kunnen beoordelen? Wat voor magische mensen hebben ze dan in dienst?

Nee, de werkelijkheid is dat keuringsinstanties ook gewoon bedrijven zijn, met gewone mensen in dienst.

[PV85]

Als je een keurmerk wil dragen moet je vaak aan bepaalde eisen voldoen.
Dus je weet dat iets wat het keurmerk draagt minimaal aan die zaken voldoet.

[De Dona]

Ik denk dat wanneer Google een dergelijk bestandssysteem in een draaiende omgeving gaat gebruiken, het wel al vantevoren uitvoerig getest zal zijn. Het mag dan ook zeker als volwassen worden beschouwd. Er staat ook dat het bestandssysteem hiermee 'opnieuw' als volwassen wordt beschouwd.

[Verwijderd]

Als het zo volwassen is... waarom moet Google dan de hoofdontwikkelaar in dienst nemen voor de migratie?

Dat klinkt eigenlijk meer alsof ze nog bergen problemen verwachten!

[Mellow Jack]

Uuuhm wat doe jij als je SAP wilt implementeren? Je zoekt naar een SAP specialist die dat voor je kan doen... Wat doe jij als je een enorm groot aantal servers wilt migreren naar een nieuw FS? Je zoekt een specialist... en waar kan je een betere specialist vinden dan deze heer?

[FRD]

Ik denk wel dat google dit eerst op voorhand goed getest heeft (zoals ook in de tekst staat) door het een hele tijd op een paar servers ofzo te draaien, dus als het na de tests en vergelijking met andere bestandssystemen er als beste uit komt moet het zijn dat het toch goed is é!

Het is wel zot dat ze zomaar een hoofdontwikkelaar inhuren hiervoor, zou ik ook Linus Torvalds mogen inhuren als ik van windows naar linux overschakel? Google begint toch wel veel macht te krijgen..

[Reactie gewijzigd door FRD op 23 juli 2024 06:00]

[RitBit]

Als je hem maar betaald...
Waarom zou dat niet mogen ?

[lembregtse]

Wat heeft dat met "te veel macht" te maken? Google heeft gewoon aan die persoon gevraagd of hij dat wilt komen in goede banen leiden. Die persoon heeft daar positief op geantwoord, wat is daar mis mee?

[FRD]

ok, het is wel waar, maar ondertussen heeft google hem wel, wat de machtspositie van google weer verhoogd door een andere top-programmeur in zijn gamma te hebben. Gelukkig blijft die programmeur zijn werk voor ext-4 en andere projecten nog doordoen.

[Hero of Time]

Maar wat zou Google dan met hem verder doen als het project is afgerond en alle servers Ext4 draaien? Hij is aangenomen voor dit project, wat erna komt zien we dan wel weer maar vraag mij af of hij zal blijven. Mogelijk dat hij terug gaat naar de Linux Foundation waar hij vertrok.

[jip_86]

Ja weet je, hij moet altijd zelf nog ja zeggen Google kan hem niet dwingen.

Als ik zelf ext4 had gemaakt en een bedrijf als Google komt je vragen mee te helpen zou ik ook direct ja zeggen. Een project op zo'n schaal meehelpen lijkt me een meer dan interessante uitdaging. Kennis die hij opdoet kan hij ook weer investeren in doorontwikkeling van ext.

[GamingZeUs]

Ik denk eerder dat de ext-4 ontwikkelaar zijn kans schoon zag om zijn bestandssysteem te verspreiden ;P

Ik zou zeggen dat dit project ook gestart zou kunnen worden in samenwerking. Maar dan moet google weer bedrijfsgeheimen bekend maken.

[blouweKip]

Google begint toch wel veel macht te krijgen..

Je bedoeld geld? het gebeurt overigens vaker dat bedrijven ontwikkelaars van software op de loonlijst hebben staan als ze grootgebruiker van die software zijn, maar ja: dat past natuurlijk niet in het google is evil adagium dat de ms-kliek probeert uit te dragen

[Franckey]

Ik neem aan dat een server van Google wel even down mag zonder dat dat problemen geeft. Het is dan toch gewoon een kwestie van een backup maken, schijven formatteren in ext4 formaat en dan backup terugzetten?

[dutch_warrior]

Ik denk niet dat je over even een backup maken en die dan terugzetten kan spreken bij de storage oplossingen welke google gebruikt .

[_eXistenZ_]

Ze hebben dan ook heel veel servers, dus server per server kan je misschien best even backuppen en terugkopieren hoor

[Verwijderd]

Kan, maar het kan ook zonder backup en restore (hoewel een backup altijd aan te raden is voor als het mis gaat, geheel risicoloos is het natuurlijk nooit).

Hier staat bijvoorbeeld hoe je dat in Ubuntu doet.

Ik neem aan dat ze het online doen, aangezien de keuze op ext4 (en niet xfs) was gevallen omdat het makkelijker upgraden is vanaf ext2.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 06:00]

[Goderic]

Een ext2 partitie kan gewoon gemount worden als ext4, formatteren is dus zelfs niet nodig.

[HoppyF]

Hoe grappig.
Ts'o heeft zelf over ext4 gezegd:

Ts'o verwacht dat ext4 zo'n vijf jaar gebruikt zal gaan worden. Daarna moet btrfs zijn uitontwikkeld. “btrfs heeft interessante dingen die wij niet konden doen, omdat we backward compatibel wilden zijn. btrfs moet nog groeien en mensen moeten er aan wennen. ext4 hadden we nodig als tussenpaus."

Er zijn dus betere alternatieven dan ext4, zoals btrfs en zfs.

[Wulfklaue]

Ik dacht dat Zfs niet meer door ontwikkeld word, of ben ik mis?

btrfs is nog veel te jong. En nog niet deftig genoeg getest voor productie servers. Zoals Ts'o zelf aangaf, zal het nog enkel jaren duren eer btrfs een niveau behaald dat bruikbaar is voor productie servers.

Persoonlijk gebruik ik xfs, maar met een UPS ofcourse. Maar een algemene regel is, de root partitie op ext3 te behouden.

Tot op heden, is mijn ervaring met de verschillende fs, dat xfs, en ext3 beiden in zeer zeldzame gevallen kunnen eindigen in een beschadigde file systeem. 1-1 score. Maar zoals ik zeg, zeldzaam, en vaak gelinked aan een power failure ( om deze reden is een UPS vrij nuttig ).

[_JGC_]

ZFS is ontwikkeld door Sun en is niet GPL-compatible, dus gaat niet in de linux kernel opgenomen worden zolang ze de licentie niet aanpassen. Aangezien ik dat laatste niet zie gebeuren komt er geen in-kernel ZFS.
Als google over wil gaan op ZFS moeten ze naast een nieuw filesystem ook overstappen op Solaris of FreeBSD.
Wat betreft ZFS ontwikkeling: Het zou oorspronkelijk in Mac OS X opgenomen worden, maar Apple heeft daar vanaf gezien. Onder FreeBSD en Solaris wordt ZFS nog gewoon doorontwikkeld.

[Dim]

Ik dacht dat Zfs niet meer door ontwikkeld word, of ben ik mis?

Je bent mis. Er wordt nog druk gesleuteld aan ZFS. Op dit moment is ZFS het meest geavanceerde open source filesystem, dat ook werkelijk in productie gebruikt kan worden. De vraag is alleen hoe lang Sun het sponsoren van dit project nog gaat volhouden.

ZFS is gewoon niet bruikbaar voor de Linux community, omdat het onder een licentie valt die onverenigbaar is met de GNU GPL. Er zijn wel oplossingen mogelijk met FUSE, net zoals met NTFS gedaan wordt, maar dat is te traag voor productiegebruik. Bovendien kan je er dan niet van booten.

Voor Linux is btrfs de "way to go", althans op de lange termijn. Het duurt nog wel een paar jaar voordat dat helemaal stabiel is. En als je iets graag stabiel wilt hebben, dan is dat wel je filesystem.

[icewind1991]

Btrfs is inderdaad in teorie beter dan ext4 maar nog niet stable.
van zfs weet ik bijna niks dus ga ik niks over zeggen
Ook is ext4 een handige keuze omdat het makkelijk is een ext2 filesystem te converteren naar een ext4 met behoud van data.

[Toettoetdaan]

zoals in je post staat, Over 5 jaar ja.

[HoppyF]

5 jaar is zo om.
De uitspraak van Ts'o is uit 2009.

[Olaf van der Spek]

Ja, maar tot die tijd is btrfs dus (waarschijnlijk) geen goede optie. Google heeft nu een oplossing nodig, niet pas in 2014.

[Reactie gewijzigd door Olaf van der Spek op 23 juli 2024 06:00]

[ppl]

Dan vraag ik me af hoe snel Google is in de migratie naar ext4 op al haar servers waar dat nodig is. Als dat ook al 5 jaar is dan draaien ze over 5 jaar pas op ext4 en kunnen ze pas over 5 jaar daadwerkelijk de vruchten er van plukken (tussendoor ook wel maar in mindere mate). Dan rijst de vraag of wachten op btfrs niet wat handiger zou zijn.

[Mellow Jack]

Omdat het compatible is met ext2 zal niemand precies weten hoelang de overstap duurt omdat ze dit "live" gaan doen

[Antipater]

5 jaar is wel een eeuwigheid in IT land. Dan zitten we 10 Ubuntu versies later, Fedora 24 en wellicht Windows 9 of wel op Chromium OS te typen. Daarnaast is ext2 nu al bejaard.

[Verwijderd]

Ik dacht dat Google voor hun opslag Google FS gebruikte? En niet ext2 ?

http://en.wikipedia.org/wiki/Google_File_System

[Verwijderd]

Dat gebruiken ze o.a. voor de databestanden van de search engine en voor de backend van subversion, maar het is niet voor alles bruikbaar (vb. niet voor de systeempartitie).

[naikon]

Google FS is een laag bovenop Ext2. Van iemand van Google heb ik een keer vernomen dat dit is omdat dit het debuggen en beheer makkelijker maakt. De backing files van GoogleFS zijn dan namelijk gewoon voor normale (Linux) tools toegankelijk.

[El Cid]

Waarom wordt JFS altijd zo ondergewaardeerd? Dat bestandssysteem is bijna niet kapot te krijgen en heeft een goede algemene performance. Tijdens testen waarbij verschillende bestandssystemen zwaar werden mishandeld(tientallen keren de stekker eruit tijdens schrijfacties bijvoorbeeld) kwam JFS er altijd als beste uit. De integriteit van je data is toch nog altijd de belangrijkste taak van een bestandssysteem. Daarom gebruik ik vrijwel altijd JFS, zeker voor fileservers.

[WhiteDog]

Ik kan je volgen, alleen heeft Google dat niet "nodig" omdat ze de data zowieso al redundant maken over verschillende servers in verschillende datacentra. Gaat er is een schijf of server stuk maakt het niets uit. Valt de stroom uit, ook niks aan de hand. Is er data stuk repliceren ze die gewoon weer even van ergens anders

Verder snap ik ook niet waarom er nog dataverlies is anno 2010. Ik heb in 20 jaar nog nooit een een filesystem zien stuk gaan (FAT, NTFS) op een PC of server. Waarom dit bij bepaalde linux filesystems wel nog het geval is begrijp ik dus niet. Performance > redundant ?

[bzerk]

Filesystemen gaan aan de lopende band kapot. Als jij dat in 20 jaar niet gezien hebt ben je ofwel:

- Guus Geluk
- Je hebt een systeem dat je zou moeten patenteren want daar kun je rijk van worden
- Je hebt een selectief geheugen.
- Je hebt in een grot gewoond

Je zegt zelf al dat schijven en servers stuk kunnen gaan. Dat geld ook voor memory, databussen etc, die een sluipende corruptie van de data on disk kunnen veroorzaken.

Het enige FS dat ik tegen ben gekomen dat dit soort (hardware) corruptie kan detecteren en corrigeren (althans in theorie) is ZFS. Maar dat is weer een resource vreter en denk ik voor Google niet geschikt.

[thegve]

Ik heb toevallig vandaag nog een laptop met een XP in een Vmware omgeving, die bij het verwijderen van een directory aangeeft "controleer of de schijf is beveiligd tegen schrijven", op de C-schijf.
In een 'normale' situatie heb ik verder ook, tot nu toe (behalve deze XP installatie) nog nooit een filesystem corrupt zien raken. Wel op het moment dat de schijf er ook geen zin meer in had, of met stroomstoringen. Meestal wel recoverable. (ext3)

[_JGC_]

Ik hoor wel meer verhalen over delayed allocation waarbij dataverlies zou optreden. Ik denk alleen niet dat Google daar veel last van zal hebben: het treedt voornamelijk op bij crashes of stroomuitval. Gezien de keuze van het huidige filesystem zal dat wel geen issue bij google zijn, als je tegenwoordig nog serieus ext2 in produktie gebruikt moet je wel heel zeker zijn over je stroomvoorziening en stabiliteit van je servers.

[TD-er]

als je tegenwoordig nog serieus ext2 in produktie gebruikt moet je wel heel zeker zijn over je stroomvoorziening en stabiliteit van je servers.

Of je systeem zo opgezet hebben dat feitelijk elke server redundant is.
Dat is bij Google het geval.

[BeosBeing]

Tja, waarom dan geen ext3? (Google wilt geen journalling?)

Nadeel voor mij van Ext4 t.o.v. Ext3 (of Ext2) is dan weer dat er geen filesystem-driver beschikbaar is voor mijn dualboot-Windows. Ext3 en Ext2 lukt dan weer perfect via de IFS-driver. http://www.fs-driver.org/

[Reactie gewijzigd door BeosBeing op 23 juli 2024 06:00]

[dinoballz]

Stroomuitval zal dan ook gedeeltelijk eigen schuld zijn omdat ze laatst immers hun eigen energieleverancier zijn geworden.

[dasiro]

ze hebben niet naast elk datacenter een centrale staan en niet alle datacenters zijn constant gerepliceerd

[GamingZeUs]

Bronnen jongens, echt.
Zonder wordt dit echt een hele wazige discussie. (persoonlijk denk ik dat google heel handig met zijn datacenters omgaat, en dat ze daarom stroomuitval niet als het grootste probleem beschouwen.)

[Aghilas]

(persoonlijk denk ik dat google heel handig met zijn datacenters omgaat, en dat ze daarom stroomuitval niet als het grootste probleem beschouwen.)

Bron?

[Olaf van der Spek]

Pfff: persoonlijk denk ik

[markg85]

Alleen jammer dat sinds ext4 in de kernel zit de performance per release achteruit is gegaan. In veel gevallen wint ext3 inmiddels!

Kijk hier maar is: www.phoromatic.com/kernel-tracker.php

[Yoshi]

waar zie jij dat staan in je bron? Misschien en waarschijnlijk dat ik erover zie, maar het is dan ook een geweldige lijst... met geen orde...

[markg85]

daar is idd wat moeilijk lezen, maar uit benchmarks als dit: http://www.phoronix.com/s...nux_2632_benchmarks&num=1 en dit: http://www.phoronix.com/s...m=ext4_btrfs_nilfs2&num=2 en dit: http://www.phoronix.com/s...em=fedora_9_11_perf&num=6 is toch wel een heel duidelijk patroon zichtbaar dat ext3 veel wint en ext 4 eigenlijk steeds meer verliest..

Zoek op die site maar naar benchmarks van meerdere linux kernels of ext4 of beide.

[halfgaar]

Vanaf welke kernel versie is ext4 dan niet meer gevoelig voor die delayed allocation?

edit: laat maar:

The new patches are expected to become part of the mainline kernel 2.6.30. Various distributions may choose to backport them to 2.6.28 or 2.6.29, for instance Ubuntu made them part of the 2.6.28 kernel in version 9.04

[Reactie gewijzigd door halfgaar op 23 juli 2024 06:00]

[448191]

Aha. Daarom had ik opeens geen fs corruptie meer nadat mijn gf weer eens de waterkoker en magnetron tegelijk aan had gezet een paar maanden geleden.