Ext4-bestandssysteem komt eindelijk uit ontwikkelfase

Door Theodore Ts'o zijn patches voor ext4 aan de Linux-kernel toegevoegd waardoor dit bestandssysteem na twee jaar van ontwikkelen en testen af is. Vanaf de volgende release van kernelversie 2.6.28 zal ext4 voor iedereen beschikbaar zijn.

Het ext4-bestandssysteem is ontwikkeld onder leiding van Ts'o en hij was het ook die de recente patch leverde waardoor ext4dev hernoemd werd naar ext4, schrijft Heise Online. Hiermee werd de stap van een bestandssysteem dat nog in ontwikkeling is naar een file system dat stabiel genoeg is voor dagelijks, intensief gebruik officieel bezegeld. Door Ts'o en enkele collega's is sinds kernelversie 2.6.19, die november 2006 verscheen, aan de ontwikkeling van het ext4-bestandssysteem gewerkt. Informatie over de verbeteringen in ext4 ten opzichte van ext3 zijn in een eerder artikel van ons te vinden.

De naamsverandering van het bestandssysteem vormt niet het einde van de ontwikkeling van ext4. De komende tijd zullen er – ondanks dat er vele uitgebreide testen zijn uitgevoerd met het bestandssysteem – bugs opduiken die opgelost moeten worden. Daarnaast zullen er nog kleine verbeteringen doorgevoerd worden, mocht daar veel vraag naar zijn. De structuren van het bestandssysteem op de opslagmedia zullen daardoor echter niet aangepast worden, zodat ext4 normaal gebruikt kan worden in productieomgevingen.

Of al deze aanpassingen en de beloofde stabiliteit voldoende zijn voor beheerders van Linux-systemen om direct de overstap naar ext4 te maken is nog de vraag. Naar alle waarschijnlijkheid zullen de meeste van hen de kat uit de boom kijken en wachten totdat er een goede mogelijkheid is om ext4 te gaan gebruiken, bijvoorbeeld bij het opnieuw opzetten van servers. Waarschijnlijk zal het proces van overstappen van ext3 naar ext4 minstens zo lang duren als dat van ext2 naar ext3.

Reacties (101)

[Verwijderd]

Ik heb het bericht over ext4 doorgelezen (verbeteringen) en de grooste verandering is, als ik het goed begrijp, dus de maximale opslag ruimte?
Dus geen speciale snelheids veranderingen (als dat al mogelijk is)

[deadinspace]

... de grooste verandering is, als ik het goed begrijp, dus de maximale opslag ruimte? Dus geen speciale snelheids veranderingen (als dat al mogelijk is)

Dat is inderdaad de belangrijkste verandering ja, maar wel eentje die onderhand nodig is. Ext3 ondersteunt maar 8 terabyte^*, en dat is zelfs een voor hobbygeld haalbare grootte tegenwoordig.

Als het verhogen van de groottelimit de enige verbetering zou zijn, dan nog zou ext4 welkom zijn, als het de betrouwbaarheid van ext3 voortzet. Ext3 is niet voor niets de standaardkeuze van de meeste distributies, maar als je tegen die 8 terabyte grens aanloopt wordt het vervelend

Maar ext4 heeft nog wel meer te bieden dan dat. De belangrijkste punten op een rijtje:

• Maximum grootte verhoogd van 8TB^* naar 1000.000TB
• Maximum filegrootte verhoogd van 2TB^* naar 1000.000TB
• Extents maken het mogelijk grote stukken ruimte (tot 128MB^*) te alloceren, wat fragmentatie vermindert en performance bij grote files kan helpen
• "persistent preallocation" (goed gejat van XFS ) maakt het mogelijk om alvast ruimte te reserveren maar nog niet te vullen. Wederom goed voor fragmentatie en performance bij grote files die on-the-fly gevuld worden
• Het aantal subdirectories verhoogd van 32.000 naar 64.000
• htree indexes staan standaard aan, voor betere performance in grote directories
• Het toevoegen van journaling checksums verhoogt de betrouwbaarheid, en de snelheid ook een beetje
• Snellere filesystem checks, door de nieuwe mogelijkheid ongebruikte delen van het filesystem over te slaan bij het checken
• Multi-block allocation zorgt ervoor dat grote stukken in één klap gealloceerd kunnen worden, in plaats van als individuele blocks. Ook dit zou fragmentatie weer een beetje tegen moeten gaan, en kan de performance van het schrijven van grote files verbeteren

Hoofdzakelijk snelheidsverbeteringen (met name voor grote files en ivm fragmentatie) dus. Niets baanbrekends, maar het zijn welkome verbeteringen.

Het Wikipedia artikel geeft een mooi overzicht (ik heb de meeste van mijn punten ook daar vandaan) met wat meer detail. Er staan ook nog wat dingen in die ik niet genoemd heb.

^* Uitgaande van een blocksize van 4KB, wat bij grote filesystems vrijwel altijd de default is, en op de meeste architecturen ook het maximum is.

[Laurens-R]

met zo'n maximale blokgrootte moet je ook zeker weten dat er alleen maar grote files op die partitie gezet worden anders kost een simpele tekstfile je al 128 MB van je schijf...beetje zonde

[Reactie gewijzigd door Laurens-R op 26 juli 2024 16:11]

[HoeZoWie]

Bedankt, super uitleg!
'k wou dat andere Tweakers dat ook deden...

[EdwinG]

Als ik het andere artikel goed heb doorgelezen is ext4 tevens een stuk efficiënter in omgang met grotere bestanden. (Door het gebruik van de extends)

[Jasper Janssen]

Het zou veel interessanter zijn als een nieuw FS beter met kleine bestanden kan omgaan (maildirs!). Reiser was daar altijd goed voor, maar is nooit echt stabiel genoeg geworden voor production use.

[borft]

niet stabiel genoeg? verklaar je nader? Ik heb een newsserver met een paar 100 gebruikers draaien op reiserfs, draait prima, nog nooit problemen gehad. En in het geval van een crash, dan is reiserfsck echt een heldenprogramma!

[Verwijderd]

Het is volgens mij maar net wat je ervaringen zijn, ik heb 2 crashes meegemaakt die ik niet kon fixen met reiserfs. Waarvan 1 een hele tijd geleden dus dat kan meer aan mijn prutsen liggen dan aan reiserfs to be honest. Maar ext3 heeft mij nog nooit in de steek gelaten dus ik kies altijd voor ext3 (tenzij je idd mailservers gebruikt want ext3 kon volges mij niet zoveel files in een directory kwijt en heeft geen dynamische inodes en bij blokken van 4k kun je krap komen te zitten met je inodes.)

Tevens zou zoeken ook sneller moeten gaan met ext4.

kan niet wachten om te proberen!

[Verwijderd]

en bij blokken van 4k kun je krap komen te zitten met je inodes.

Kwestie van nadenken voor je formatteert, het aantal inodes / kb is in te stellen. Ik heb /var/spool op een aparte partitie met meer inodes / kb dan de default instelling. Noodzakelijk voor m'n usenet server met wat tekstgroepen (berichen in groepen worden als allemaal losse files opgeslagen).

[Verwijderd]

Ik ben wel een keer in de steek gelaten door ext3, ik verloor steeds meer ruimte zonder duidelijk aanwijsbare reden. Toen ik vervolgens fsck draaide werd het complete fs verneukt. Dat was voor mij de aanleiding (omdat ik sowieso al vond dat Debian (wat ik destijds gebruikte) ernstig achteruit gegaan was) om te migreren naar FreeBSD. Inmiddels draait die bak al ruim drie jaar zonder enig probleem, lang leve FFS2...

Met ReiserFS heb ik zelf geen ervaring maar het had begin deze eeuw in elk geval de reputatie zeer betrouwbaar te zijn.

[Verwijderd]

ReiserFS is redelijk stabiel en zeker supersnel. Maar vanwege het superblock niet echt de ideale keuze als je uptime moet garanderen. De kans op problemen is niet heel groot, maar je zult maar even een backup terug moeten zetten van een live systeem.

[Verwijderd]

Reiser FS is lange tijd de standaard geweest bij SuSe. Toch een distributie die voor serieuze taken wordt gebruikt. Alleen met de rechtzaak tegen Hans Reiser is het filesystem impopulair geworden.

Ik heb het in gebruik sinds de tijd dat SuSe nog uit Duitsland kwam. Nog nooit een serieus probleem tegengekomen.

[Verwijderd]

Hopelijk doen ze iets aan het gulzige beheer van de schijven want ext3 vergeleken met ntfs van windows scheelt een dikke pak gigabytes verlies op grote schijven.

[Brent]

Hopelijk doen ze iets aan het gulzige beheer van de schijven want ext3 vergeleken met ntfs van windows scheelt een dikke pak gigabytes verlies op grote schijven.

Je bedoelt waarschijnlijk de gereserveerde ruimte voor root (standaard 5%). Vanaf de commandline kun je die gewoon op 0% zetten. Met LargeFile kun je de ruimte gereserveerd voor inodes ook een stuk terugzetten waardoor de 'verloren' gelijk of minder is dan NTFS als het me goed bijstaat.

[freaky]

Evt. kan het ook in block grootte zitten. 1000 bestandjes van 1k op 1M blocks zuigen behoorlijk aan je schijfruimte om maar een extreem voorbeeld te noemen.

[deadinspace]

Ext2/3/4 ondersteunen op de meeste architecturen (lees: alles wat niet alpha heet) een blocksize van maximaal 4KB.

Hoewel je daarmee natuurlijk nog steeds ruimte verliest op kleine bestanden is het iets minder erg dan jouw 1MB-blocks situatie

[MSalters]

Ext2/3/4 ondersteunt rustig een 64KB blockgrootte op x86. Het is "maar" een diskformaat, en de benodigde datastructuren on disk zijn groot genoeg. De linux x86 Ext2/3/4 drivers zijn het probleem. Die kunnen niet omgaan met een 64KB block, omdat ze veronderstellen dat de 4KB memory pages 1 of meer disk blokken nodig hebben. Met een 64KB block in Ext2 zou een RAM page dus maar 1/16de block nodig hebben.

[MoonWatcher]

Zelf mis ik nog een transparante compressie plugin voor "een" bestandsysteem in linux. ( en nee, die fuse rotzooi komt het datacentre niet in... )

Zeker voor backup machines scheelt dit al snel een hele bak data. cpu performance is daar ook meestal geen probleem.

Toch is ext4 zeker een grote verbetering ten opzichte van zijn voorganger.
Ik zou mijn servers er nog niet meteen aan toe vertrouwen maar ik ga het zeker in de gaten houden.

[deadinspace]

Zelf mis ik nog een transparante compressie plugin voor "een" bestandsysteem in linux. [...] Zeker voor backup machines scheelt dit al snel een hele bak data. cpu performance is daar ook meestal geen probleem.

Backup software compressed zijn files toch zeker zelf wel? In dat geval heb je niks meer aan compressie op filesystem nivo. Sterker nog, dat werkt waarschijnlijk alleen maar tegen.

( en nee, die fuse rotzooi komt het datacentre niet in... )

Wat is er mis met fuse? De performance kan in sommige gevallen wat beter, maar je haalt hier nou net een situatie aan waarvoor de performance minder belangrijk is...

[Verwijderd]

Compressie van een bestandensysteem kan ook voor een versnelling zorgen, zoals in ZFS. Het zorgt dat er minder data door de controller hoeft om gegevens te lezen/schrijven. Oh ja, het zorgt ook voor minder verbruik van ruimte... Maar daar hoef je je niet druk om te maken op ZFS omdat het geen beperkingen heeft zoals partities en files, bovendien dynamisch uit te breiden gedurende produktie.

ext3 max 8TB, ext4 max 1000.000TB... mooie verruiming, maar nog steeds met harde limiet.

Voor de mac en *BSD is er al ZFS ondersteuning, hetzij dat het nog niet de volledige featureset ondersteund. Voor Linux d.m.v. Fuse heeft men een begin gemaakt, maar zal nooit native kunnen draaien onder Linux omdat de opensource licentie van ZFS niet GPL is. (maakt dat de gemiddelde Linux gebruiker wat uit? )

Voor backup is ZFS ook handig omdat je gewoon previous versions terug kan zetten zonder dat het je hele schijf opslokt of performance kost.

ZFS is langere tijd productie stabiel, en nu komt de Linux community met ext4?
Ik zou wel eens een performance test willen zien van ext4 (met hardware raid) tegen ZFS (native, geen Fuse) met software raid.

OpenSolaris (productie stabiel) draait native op ZFS en kan Linux applicaties in containers draaien. Echter als je Linux wilt virtualiseren op OpenSolaris kun je ook gewoon xVM server draaien (o.a. live migratie tussen fysieke systemen, en meer..) of in VirtualBox. Je kunt er zelfs commerciele ondersteuning voor krijgen als je dat wilt.

[dtech]

In de unix wereld is het natuurlijk niet ongebruikelijk om gewoon te backuppen door bestanden te kopiëren, met rsync bijv.

Wat fuse betreft, ik denk dat MoonWatcher niet zoveel vertrouwen heeft in fuse en de drivers daarvan. Kan ik me iets bij voorstellen, als iedereen een fs driver kan maken zit daar natuurlijk een boel rotzooi tussen. Er is echter genoeg professioneels verkrijgbaar (onderhouden door grote communties, red hat, novell e.d.)

[Laurens-R]

Een fs driver is niet echt iets wat iedereen kan maken kan ik je verzekeren. Het vereist een bepaald kennisniveau wat ver voorbij de gemiddelde hobbyist ligt. Je hebt er een redelijke computer sceince knobbel voor nodig

Daarnaast is de NTFS driver van fuse trouwens best goed

[Jeanpaul145]

Waarom noem je Fuse rotzooi? Omdat het wat trager is misschien? Dat maakt het enkel ongeschikt voor jouw doeleinden misschien, maar om het dan rotzooi te gaan noemen vind ik wel vrij kort door de bocht.

Als het niet voor de performancehit was zou ik *al* mijn datapartities via fuse mounten (en indien mogelijk, misschien zelfs de bootpartitie), al is het alleen maar dat de mogelijkheid van een crash in de kernel vanwege een filesystem driver daarmee wegvalt.
Dat gezegd hebbende, filesystems zijn meestal wel heel, heel, heeeel stabiel.

EDIT: typo's

[Reactie gewijzigd door Jeanpaul145 op 26 juli 2024 16:11]

[Sir Isaac]

Bedoel je niet gewoon de hoeveelheid schijfruimte die voor root is gereserveerd? Dat is standaard 5% en voor een 400Gb schijf is dat inderdaad nogal veel. Je kunt dit met tune2fs non-destructief aanpassen.

[borft]

of je kunt het bij het aanmaken van het fs, met mkfs.ext3 gewoon als cmdline parameter meegeven: mkfs.ext3 -m 0

[dcm360]

Die zal je even moeten verduidelijken Als je het over gigabytes hebt op grote schijven dan zal ik daar toch echt al wat van moeten merken op 92GB, maar ik merk geen verschil...

[Reactie gewijzigd door dcm360 op 26 juli 2024 16:11]

[n4m3l355]

Ik vind het wel meevallen, ik meende ooit bij 200Gb een kleine 3Gb te verliezen met ext3 tov ntfs. Imo is dat toch geen noemenswaardig verschil. Dat tov de performance en stabiliteit die EXT3 vertoond lijkt het me toch een snelle keus.
Verder Fuse en rotzooi... geen idee waar dat vandaan komt. Heden ten dagen is Fuse toch wel stukke sleaker dat er geen performance verlies meer optreed.

[onox]

Bij FUSE dient nog steeds een brug gemaakt te worden tussen kernelspace en userspace en dat kost nou eenmaal performance. Desondanks maakt FUSE wel coole dingen als sshfs en encfs mogelijk.

[psyBSD]

Ik kan mij niet voorstellen dat mensen hier NTFS nog steeds een beter filesystem noemen dan het spul dat beschikbaar is onder *nix.

Mag ik jullie eraan herinneren microsoft NOG STEEDS GEEN filesystem heeft ontwikkeld dat on-the-fly defragmenteert.

[Verwijderd]

@psyBSD....

Microsoft heel al heeeeeel lang geleden een filesysteem ontwikkeld dat on-the-fly defragmenteerd. Namelijk HPFS!

HPFS mag dan hoofdzakelijk onder OS/2 gebruikt worden, het is echter wel door Microsoft ontwikkeld, en niet door IBM! En HPFS fragment on-the-fly. En beter dan enig ander filesysteem dat ik ooit heb gezien. Bij OS/2 had ik na vele maanden werk een maximum van 4 fragmenten per file over mijn gehele disk... (Natuurlijk, de laatste versies van HPFS zijn doorontwikkelingen van IBM, maar de basis is niet veranderd).

Is me nooit duidelijk geworden waarom Microsoft geen HPFS gebruikt, of waarom ze niet de goede punten van HPFS en NTFS op de een of andere manier gecombineerd hebben. Een van de voordelen van NTFS t.o.v. HPFS was in ieder geval het ingebouwde rechten systeem, en encryptie. Maar dat lijkt niet iets dat direct iets met maken heeft met fragmentatie kwestie.

[Dreamvoid]

Je geeft zelf al het antwoord op de vraag - voor MS waren blijkbaar features als encryptie/rechten belangrijker dan defragmentatie. Ergens ook logisch - rechtenbeheer bovenop het filesystem implementeren is een stuk lastiger dan eens in de zoveel tijd een defrag service draaien.

[pinockio]

Ja, in bepaalde opzichten wel. In andere opzichten is ext3 al weer beter dan NTFS, en ext4 zal ongetwijfeld bepaalde beperkingen van ext3 niet hebben. Maar op andere vlakken (encryptie, compressie) heeft NTFS meer mogelijkheden en is dus "beter".

[dsmink]

Dude, jij snapt het echt niet he?

Maar op andere vlakken (encryptie, compressie) heeft NTFS meer mogelijkheden en is dus "beter".

Volgens mij zijn dat gewoon net die 2 vlakken waar jij wat meer waarde aan hecht? En omdat jij er meer waarde aan hecht is het per definitie beter.

Het is geloof ik al eerder tegen je gezegd...

Jij pikt er nu 2 dingen uit die ext4 niet kan en NTFS wel. In een eerdere post gaf iemand aan wat ext4 wel kan en NTFS weer niet.

Het is dus niet beter, het is ook niet per definitie slechter ik denk dat het net een beetje aansluit bij de rest van het OS.

Linux heeft namelijk zelf weer heel andere tools voor compressie en encryptie, waar het bij Windows wellicht door het filesystem afgehandeld wordt. Doe nou gewoon eens niet zo stront eigenwijs en houd eens op met dat gezeur! Dit draadje gaat over ext4, niet over NTFS. En al helemaal niet over welke er beter is.

[pinockio]

Geef jij dan eens aan waarom voor een gebruiker die 2 features (waarvan ik in ieder geval nog nooit gehoord heb, en ook niet gebruikt heb) die ext2/3/4 dan meer zou hebben dan NTFS zoveel schelen.

Geeft voor mij wel weer aan dat veel Linux developers (gelukkig lang niet allemaal) het leuker vinden om iets te ontwikkelen wat ze gewoon cool vinden, maar waar de gebruikers niet om vragen.

Dus ja, ext4 loopt op bepaalde vlakken nog steeds achter, NTFS op andere, mag ook wel na 15 jaar zonder schokkende nieuwe ontwikkelingen. Maar goed, voor mij voldoet ext3 voor de meeste toepassingen, mij hoor je niet klagen hoor.

[Reactie gewijzigd door pinockio op 26 juli 2024 16:11]

[Ulysses]

Het kan aan mij liggen hoor, maar ben ik de enige die vind dat het vergelijken van Ext3/4 met NTFS appels en peren is? Ik bedoel, ik heb nog nooit de behoefte gevoeld om mijn Windows bak op Ext3 te laten draaien en omgekeerd zou ik ook mijn Linux bak nooit op NTFS installeren .... Dus waar komt het uiteindelijk op neer? De oeroude discussie MS vs. Linux ... nou, dat lijkt me niet een slim onderwerp, want da's netzoiets als over het geloof gaan praten in een kroeg ... binnen de kortste keren is de sfeer verziekt.

[SuperNull]

Als je zowel Linux als Windows op de zelfde bak hebt (met een dual boot of met virtual machines) dan wil je meestal wel dat OF je Windows Ext3 OF je Linux NTFS kan lezen.

Een Fat32 partition als middleman gebruiken is knudde omdat Fat32 geen grotere files dan 4GB aan kan. (daar gaan je DVD iso's)

De NTFS support op Linux is tegenwoordig geen enkel probleem (zolang we het niet over de root partition hebben).

[Dreamvoid]

Dat is geen eigenschap van het FS zelf, maar een kwestie of het OS een continue op de achtergrond aanwezig defrag/allocatie proces heeft draaien.

[psyBSD]

Niet helemaal, onder linux heb ik nl nooit een defrag proces draaien. Dat gebeurt 'slim' tijdens het wegschrijven van de data naar de schijf.

Dus, 'real-time'. Het feit dat de NTFS driver niet in staat is om op deze manier fragmentatie te voorkomen is een tekortkoming van Microsoft.

[funkwurm]

Dit is zeker net te laat voor de komende Ubuntu 8.10, of niet?

[jj71]

Ja, Ubuntu 8.10 maakt gebruik van kernel 2.6.27 (dus niet .28 waar ext4 in zit), en komt over 10 dagen uit. Er is al een tijdje een "freeze" van kracht voor Ubuntu 8.10, wat betekent dat de lijst van software en versies nu vast staat.

[Jasper Janssen]

'Net'? Dik.

Maar nieuwe kernelversies (waar de ondersteuning hiervoor uit bestaat) komen ook na freeze nog uit. Je zal alleen wellicht geen ext4 zien in de install.

[i-chat]

dat geeft ook nie, laat ze het eerst maar eens grondig testen in de mainstream, situatie. en verder zolang duurt het niet tot ubuntu 9.04 - bovendien, ALS er vraag naar is zul je snel genoeg zien dat er een revisie komt om dit als nog in te bouwen.

zoals je ook 8.04.1 hebt, of kubuntu 8.04 kde4 - kun je best strax ook een ..buntu ext4 versie verwachten.

[_Thanatos_]

Heeft Ext4 dan eindelijk user(group) based permissions en ownership? NTFS heeft dat al sinds versie 1.0 (Windows NT 3.5 en 4.0) dus dus al meer dan 12 jaar. Mocht wel tijd worden dat Linux ook wat flexibelere rechten-uitdeel-of-wegneem-mogelijkheden zou hebben.

En volgens mij zijn er nog wel meer puntjes waar NTFS meer mogelijkheden biedt

[Reactie gewijzigd door _Thanatos_ op 26 juli 2024 16:11]

[locke960]

Linux kan het wel met zogenaamde "extended attributes", maar volgens mij is het meer zo dat de meerderheid van de Linux gebruikers het "Keep-it-simple" principe aanhangt.

Windows met zijn ACL's is vaak erg makkelijk maar als het niet erg gedisciplineerd gebruikt wordt dan wordt het een gigantische ongeorganiseerde puinhoop.

[Verwijderd]

Mijn ervaring is precies het omgekeerde.

Het is vrijwel onmogelijk om met ACL's een puinhoop te maken. Zelfs met zeer uitgebreide complexe usergroups, is het juist uitermate simpel te beheren. Juist omdat je meerdere groups en users tegelijk toegang kunt verlenen. Dat is allemaal heel natuurlijk, om dezelfde manier als je het zonder computers ook zou doen.

Het 1 group systeem maakt het daarentegen ongelooflijk ingewikkeld. Komt er op neer dat je een ongelooflijk ingewikkelde group structuur moet maken, en voor de simpelste wijzigigen, alles weer overhoop moet gooien.

Vroeger bij de studievereninging een server met 140 users, en 50 groups. Op een Novell server. Liep allemaal gesmeerd, nooit een probleem met user rechten. Toen op Linux overgestapt. Ondanks dat we verscheidene Linux Guru's hadden, hadden we constant gelazer, dat de users niet bij hun bestanden konden. Nadat dat na twee jaar nog steeds rampzalig was, zijn we op een Windows server overgestapt. Alle problemen onmiddellijk opgelost. Net als bij Novell, is dat een kwestie van eenmaal instellen, en daarna nooit meer naar hoeven kijken. Het werkt gewoon als een zonnetje.

Daarna, bij de onderzoeks afdeling direct een Windows server gezet, en wederom liep alles als een zonnetje. Het mooie is ook dat het zo simpel en logisch in elkaar steekt, dat je zonder problemen beheerstaken kunt uitbesteden aan niet-admins, zonder dat er problemen van komen.

Hier op het MPI staat bij de onderzoeks afdeling een Suse Server, en dat levert weer exact hetzelfde gelazer met dat zogenaamde 'simple' Linux rechten systeem. Het effect is dat de enige folder op de server die volop gebruikt wordt, de 'scratch' folder is. Simpelweg omdat daar geen user restricties op zitten, en je dus nooit gelazer hebt. Bij andere folders heb je constant het gevaar dat plotseling sommigen niet meer bij een files kunnen komen. En het resultaat is dat niemand ze gebruikt. En DAT levert pas een ongeorgansieerde puinhoop!

Dat zogenaamde simpele systeem in de praktijk juist hopeloos te beheren, terwijl het zogenaamd ingewikkelde ACL's een voorbeeld van eenvoud zijn. Ongelooflijk dat de Linux distributies nog steeds niet default ACL's zijn gaan gebruiken, en dat hopeloze 1user 1group systeem overboord kegelen...

[Rostvertol-Mil]

Huh? Dat kan toch al jaren, en is makkelijk aan te passen via chmod? En als dat niet genoeg is kan je over op een MAC implementatie als selinux?

[TD-er]

Ik denk dat 'ie bedoelde meerdere user- en group-permissies.
Dus niet alleen 1 user-id en 1 group-id.

[RedShift]

Dit heeft ext3 en elk ander modern unix bestandssyteem, onder de noemer extended attributes. En een modern linux systeem ondersteund praktisch alles wat NTFS ondersteund.

[lammert]

Heeft Ext4 dan eindelijk user(group) based permissions en ownership? NTFS heeft dat al sinds versie 1.0 (Windows NT 3.5 en 4.0) dus dus al meer dan 12 jaar. Mocht wel tijd worden dat Linux ook wat flexibelere rechten-uitdeel-of-wegneem-mogelijkheden zou hebben.

Volgens mij begrijp ik je niet helemaal, zelfs ext2 bood de features die jij noemt al (in 1993, dus 15 jaar terug), laat staan ext3?

[_Thanatos_]

Hierboven genoemd. Extended attributes dus.

Of je begrijpt me niet helemaal. Dan raadt ik je aan om met XP Pro (niet Home) of een Windows server es naar de permissions tab op een file of directory te gaan. Daar kun je wel meer dan user/group/all de read/write/execute rechten geven (wat neer zou komen op 9 vinkjes).

[user109731]

Overigens word ext4 gezien als een brug naar btrfs. De ontwikkeling van dat bestandssysteem is gestart door Oracle, en is echt next-gen zoals Sun's ZFS (de licentie daarvan is helaas niet compatible met de GPL)

[MoonWatcher]

Een ander gaaf bestand systeem gebouwd door Oracle ( en ook gebaseerd op de JBD engine van ext ) is Cluster Filesysteem OCFS2

Ook dit bestand systeem gaat over op JBD2 engine van ext4
http://www.mail-archive.c....oracle.com/msg02050.html

Verder is er nog het lustre cluster filesysteem dat gebruik maakt van de JBD engine.
Van hun heb ik nog niks gehoord over een mogelijke migratie. maar dat zou me ook niks verbazen.

1 ding is zeker, de ontwikkeling op ext gebied levert voor iedereen wat op.

[Jeanpaul145]

offtopic:
Ik moet zeggen, na het lezen van het wikipedia artikel over BTRFS werd ik gelijk enthousiast. Zo lang Oracle het gpl-compatible houdt maakt dit denk ik een HELE goede kans om een opvolger te worden van Ext4 denk ik, al helemaal gezien Ext4 geen optimalisaties bevat voor SSD's.

[davidov2008]

@Gyzome, spel en tikfouten mag je hier http://gathering.tweakers.net/forum/list_messages/1310398 melden

En als je denkt dat het een eigen topic verdient http://gathering.tweakers.net/forum/list_topics/43

ontopic: ik ben geen linux expert, maar ik kan me herinneren dat de maximale partitiegrootte voor ext3 iets van 8TB was. Niet echt iets waar je als home-user (zelfs niet als tweaker ) tegenaan loopt, maar wel vervelend voor bedrijven met netwerk-servers etc... Dus in die zin is dat als 'grootste verandering' niet eens zo slecht.

Maar er zijn ook nog wat andere changes, zo kan er bij ext4 vooraf bestandsruimte voor een file gereserveerd worden, waardoor er geen 0'len meer vooraf geschreven hoeven te worden.

Daarnaast zal de journal van linux voorzien worden van checksum compatibility, om de stabiliteit van dit vaak uitgelezen bestand te verbeteren. Ook is het aantal mogelijke subdirectories binnen een map verdubbeld van 32 naar 64k (ja nuttig ). Bovendien bevat het een mogelijkheid voor het implementeren van geavanceerd defragmenteer systeem.

Tot slot zullen de tijdsstempels (laatst gewijzigd/geopend) gemeten gaan worden in nanoseconden, om de steeds sneller schrijvende HDDs bij te houden (zodat niet 2 files exact dezelfde timestamp hebben).

E.e.a. is zoals altijd te vinden op wiki; http://en.wikipedia.org/wiki/Ext4

[deadinspace]

Tot slot zullen de tijdsstempels (laatst gewijzigd/geopend) gemeten gaan worden in nanoseconden, om de steeds sneller schrijvende HDDs bij te houden (zodat niet 2 files exact dezelfde timestamp hebben).

Dat is voorzover ik begrijp niet de motivatie voor preciesere timestamps.

Om te beginnen wordt de timestamp van een file vastgelegd op het moment dat de opdracht tot aanmaken/wijzigen/lezen (afhankelijk van welke timestamp) gegeven wordt, en niet op het moment dat de harddisk daadwerkelijk in actie komt. De snelheid van harddisks maakt daarvoor dus niet echt uit.

En om verder te gaan, dat files exact dezelfde timestamp hebben is an sich geen probleem. Ik durf te wedden dat op mijn desktopsysteem zat files te vinden zijn met exact dezelfde timestamp. Het is alleen irritant als mensen/programma's met meer precisie willen weten wanneer een file is aangemaakt/gewijzigd/gelezen.

[TD-er]

Maar er zijn ook nog wat andere changes, zo kan er bij ext4 vooraf bestandsruimte voor een file gereserveerd worden, waardoor er geen 0'len meer vooraf geschreven hoeven te worden.

Houdt de kernel dan netjes bij welke delen van die file al beschreven zijn, of is dat alleen maar een pointer vanaf het begin van de file? (scheelt nogal in de complexiteit en maakt ook nogal uit in de snelheid)
Ik neem namelijk aan dat er een dergelijk mechanisme in zit, aangezien je anders een enorm veiligheidsrisico hebt.

@8TB partitie-grootte...
Dat is iets waar de tweaker al binnen 1 a 2 jaar tegenaan zal lopen, zeker nu de 1 TB schijven al zo'n 90 euro kosten. Dat is zeg maar nog geen 1000 euro aan schijven.

[lammert]

Maximale volume-size in ext3 is niet 8 maar 32 TB, voor Ext4 is dat 1 ExaByte.

[TD-er]

Als je nou mooi op het bitje tussen die 8 en 32 in gaat zitten
Wikipedia: Ext3

[pinockio]

Wat me opvalt is dat Linux qua filesystem-mogelijkheden altijd wat achterloopt op Windows (nofi). Zoals genoemd: transparante compressie.
Wat in Ext3 al beter was was journalling. Ik kan me de tijd van ext2 nog herinneren, en dat je dan na drie keer vastlopen Linux moest herinstalleren vanwege corruptie van de kernel of andere belangrijke bestanden. Windows had met NTFS al rond 1994 een journalling filesystem.

Hopelijks zorgt ext4 ervoor dat Linux eindelijk niet meer achterloopt...

[Reactie gewijzigd door pinockio op 26 juli 2024 16:11]

[johnbetonschaar]

Ik dacht altijd dat het andersom was, in de FAT32 tijd (C:\MICROS~1 ) had linux al ext2, en toen NTFS uiteindelijk een beetje door begon te dringen op de desktop (windows 2000) was er al support voor ext3, reiser, jfs, hfs+ (apple, lijkt erg op ntfs) en ik vergeet vast nog wel 1 of 2 filesystems die qua features en performance weinig onderdoen voor ntfs. Plus nog een hele berg aan network filesystems, distributed file systems, packet file systems zoals udf etc. Dus volgens mij valt het het wel mee met dat achterlopen. Read/write NTFS support is er ook al een tijdje trouwens. Je hebt in ieder geval heel wat meer keus dan bij Windows ;-)

[Reactie gewijzigd door johnbetonschaar op 26 juli 2024 16:11]

[johnbetonschaar]

Ext2 komt uit 1993 (http://en.wikipedia.org/wiki/Ext2), dus de rest van je verhaal zal ik maar negeren (als Windows, Linux en OS X gebruiker trouwens). Maar als jij vanwege (in ieder geval door jou) ongespecificeerde voordelen NTFS graag als het summum van bestandssystemen ziet en tevreden bent met de ruime keus uit FAT16, FAT32 en NTFS, jouw feestje...

[pinockio]

Jaja.... het was een typfoutje, ik bedoelde ext3 in plaats van ext2, in mijn eerdere bericht heb ik het gemis aan journalling in ext2 al genoemd, en de beperkingen daarvan. Maar ik vraag je wel om even alles te lezen wat ik schrijf. Ik heb dus wel minimaal één voordeel gespecificeerd van NTFS t.o.v. ext4 (compressie), en al twee t.o.v. ext2:

Journalling, en compressie. Het eerste vind ik trouwens véél belangrijker dan het tweede.

Ext3 werd pas vanaf november 2001 door de toen gangbare kernel ondersteund, en pas veel later gemeengoed in distributies en bij gebruikers. Bron:

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

Zo. Dan is dat in ieder geval weer rechtgezet. Nogmaals, pas EIND 2001 werd journalling aan een (gangbaar) Linux FS toegevoegd, waar dit vanaf 1993 al ondersteund werd door NTFS.

En dan over ext4.

http://en.wikipedia.org/wiki/Ext4
Transparent compression No
Transparent encryption No

Ze lopen dus NOG STEEDS achter wat betreft die twee aspecten.

En dat is de waarheid.

Nu jij weer. (Hopelijk geen typfoutjes gemaakt die sommigen de gelegenheid geven de rest van mijn ware beweringen nodeloos onderuit te halen.)

[Reactie gewijzigd door pinockio op 26 juli 2024 16:11]

[ppl]

Helaas is het ook zo dat de journaling in NTFS bar weinig doet in de praktijk. Een filesystemcrash in de praktijk betekent alsnog datacorruptie (dat journaling lijkt dan ook eerder iets te zijn wat op papier staat, je merkt er verder echt helemaal niets van, zelfs FAT32 kan zich nog meten met NTFS op dat vlak). Datzelfde valt ook te zeggen over de fragmentatie. NTFS zou hiervoor de oplossing bieden maar in de praktijk blijkt dat het nog steeds ontzettend gevoelig is voor fragmentatie en je het regelmatig dient te defragmenteren. Het is er dan wel weer ietsjes beter op geworden sinds FAT32. Theorie en praktijk zijn in geval van NTFS echt 2 totaal verschillende werelden.

Het journaling verhaal is ook bij Linux divers wegens de verschillende filesystems. Ext3 heeft een wat veiligere journaling oplossing dan reiserfs maar de laatste is dan weer heel wat sneller bij het restoren (de reden hiervoor verklaart dan ook meteen waarom ext3 veiliger is). Alles heeft zo zijn voor- en nadelen. Wie er het eerste is boeit dan ook totaal niet. Utieindelijk moet een filesystem ook bruikbaar en goed in elkaar steken, Op die punten is het toch echt NTFS die gruwelijk hard verliest. Zelfs FAT32 loopt op een aantal punten voor op NTFS (support).

Compressie en encryption zijn echt geen zaken die je specifiek in het filesystem moet hebben. Voor die dingen zijn er ook zat andere mogelijkheden. In geval van Windows is de implementatie weer op een dusdanig niveau dat de encryption key ook weer vrij eenvoudig te achterhalen is. Wat heb je dan nog aan die encryptie? Daarnaast is het niet mogelijk om een gehele schijf te voorzien van encryptie in Windows (truecrypt biedt aardig wat mogelijkheden voor Windows die we alweer een tijdje kennen in UNIX/Linux land) en dat kan weer wel in UNIX/Linux. Daarbij zijn de encryptie mogelijkheden bij UNIX/Linux ook heel wat geavanceerder dan die van NTFS. Dat het in je filesystem zit zegt dus niet veel, het gaat ook om de bruikbaarheid en de feature set. Dit uiteraard even compleet afgezien van de voordelen van het feit dat je dingen op elkaar kunt stapelen waardoor je weer een hele specifieke setup met bepaalde eigenschappen kunt maken. Op die manier kun je voordelen van diverse systemen met elkaar combineren. Dat is iets wat met NTFS bijvoorbeeld helemaal niet mogelijk is. Je krijgt NTFS en wat die versie die je dan op dat moment gebruikt ondersteund is dan ook hetgeen waar je het mee moet doen.

Alle bovenstaande zaken mis je volledig. Iemand met een objectieve blik en gezond verstand had bovenstaand verhaal wel kunnen bedenken, alleen echte NTFS-fanboys doen dat niet en beginnen dan maar te roepen dat NTFS de eerste was met feature zus en zo. Ja leuk maar ga er nou eens echt inhoudelijk op in, dan is het verhaal ineens heel anders. Gezien de totale mogelijkheden van NTFS t.o.v. andere filesystems loopt dit filesystem lichtjaren achter op de concurrentie, met name op gebied van het combineren van allerlei zaken.

[Reactie gewijzigd door ppl op 26 juli 2024 16:11]

[pinockio]

Ik ben helemaal geen NTFS fanboy, mijn mening is gebaseerd op 8 jaar ervaring. Ext2 was gewoon inferieur aan NTFS, in mijn ervaring. Zie hierboven, dat ga ik niet herhalen.

En nu missen (meerdere mensen, zie boven) dus ook transparante compressie en encryptie. Waarom dat handig is? Misschien kun je dat niet bedenken omdat je het niet gebruikt.

Nu kun je wel een heel lang en technisch verhaal houden, maar de praktijk telt, niet de theorie. Tenminste, in de wereld van de grote jongens.

http://www.velocityreview...fs-encryption-system.html

Lees dat maar even door. Alles valt te kraken, maar die EFS beveiliging is zo slecht nog niet hoor. Zeker sinds XP SP1 (sept. 2002).

[johnbetonschaar]

Kan je anders eens aangeven wat nu precies het voordeel is van transparante compressie of encryptie t.o.v. de oplossingen die linux biedt want je blijft er maar over doorgaan? Volgens mij kan je met allebei precies hetzelfde, behalve dat de verantwoordelijkheden bij Linux beter gescheiden zijn waardoor je compressie en encryptie op verschillende beschikbare filesystems kunt toepassen zonder dat de support specifiek _in_ het filesystem zit.

Volgens mij is de enige reden dat het bij NTFS 'transparante compressie' (ie: als filesystem feature en niet als extra laag over de file IO API) heet vanwege het feit dat alles voor ntfs (FAT16/FAT32) zo ontzettend simplistisch waren dat er uberhaupt geen compressie of encryptie aan kon worden toegevoegd zonder hele ranzige oplossingen (zoals je in Win95 had met drivespace), en het vervolgens rechtstreeks in NTFS is ingebouwd omdat er toch geen andere Windows filesystems zijn die er gebaat bij zouden zijn.

NTFS had idd iets eerder journalling dan ext3, tot 2000 een klein pluspuntje maar niet veel want ext3 bestond natuurlijk ook al langer dan de dag dat het in de mainline kwam te zitten, en de eerste enigzins feature-complete versie van NTFS kwam pas met windows 2000 uit (v3, tot op dat punt v1.2).

Los daarvan overschat je volgens mij de data-safety van de journalling van NTFS, het is me meer dan eens overkomen dat ik na een vastgelopen XP systeem de data niet meer terug kon halen of er allerlei spookbestanden achterbleven die ik niet meer weg kon gooien (zelfs niet als administrator) vanwege vage locks. Mijn ervaring is dat de journalling van ext3 of reiser veel veiliger is, maar YMMV. Je originele punt was in ieder geval dat Linux filesystems altijd achter liepen op Windows, het enige wat je noemt om dat hard te maken is dat je in theorie iets er eerder journalling had.

[pinockio]

Ik houd het even kort, maar moet toch even wat onjuistheden in je verhaal ontkrachten (hoewel dit nauwelijks nodig lijkt, omdat ik feiten citeer, en jij deze verdraait):

Eerder was het journalling, compressie en encryptie wat niet aanwezig was, nu is het alleen nog compressie en encryptie.

FAT32: ken je die schijfchecks elke keer na het uitzetten van je systeem? Ik kom nu nog PC's tegen, o.a. Acer, waar de C: schijf nog FAT32 heeft. Waardeloos. Bij NTFS is dat bijna nooit nodig.

Ext2: drie keer noodgedwongen de PC met de knop uitzetten, en gewoon niet meer opstarten he! (Meegemaakt. Met EXt2. In 2001. De Linux kernel ondersteunde ext3 pas vanaf eind 2001. Bron: zie gegeven link. Met NTFS NOOIT, en al tientallen malen geprobeerd.)

Ik doe regelmatig aan datarestore (softwarematig) op NTFS, en dit lukt bijna altijd. Behalve als de schijf al voor 90% of meer stuk is.

[user109731]

Transparent compression No
Transparent encryption No

Ze lopen dus NOG STEEDS achter.

En dat is de waarheid.

Grapjas, 1 feature van NTFS eruit lichten, en filesystems die dat niet ondersteunen (ik heb hierboven al een mogelijke reden daarvoor genoemd) lopen dan direct achter

Als we op jouw manier doorgaan kijk dan ook hier eens. Over journaling gesproken, NTFS heeft geen Block Journaling (dat had ext3 al), geen allocate-on-flush, geen variable file blocksize, geen tail packing, etc.

Maar omdat ext4 geen compressie/encryptie ondersteunt loopt het per definitie, zonder naar performance of andere features te kijken, direct al achter op NTFS? Lekkere redenering

[Reactie gewijzigd door user109731 op 26 juli 2024 16:11]

[pinockio]

Ik heb het vanaf het begin "achterlopen" genoemd, niet persé "beter of slechter". Features die sowieso erg nuttig zijn en ontbreken (genoemd: journalling in ext2) maken een FS inderdaad minder goed ja.

Of wou je soms zeggen dat bij een (harddisk) crash het te prefereren valt om géén journalling te hebben?

Overigens, als ik ext2 met NTFS vergelijk heeft NTFS enkele features wel die ext2 niet heeft, en de enige feature die ext2 dan extra heeft is "offline shrink" (whatever that may be). Ext3 voegt dan toe: Block journaling Metadata-only journaling en online grow maar nog steeds geen encryption en compression, en ook geen of nauwelijks andere features die NTFS niet heeft.
Bovendien noem jij enkele zaken op die weliswaar technisch misschien vooruitstrevend zijn maar geen features waar de gebruiker echt voordeel bij heeft.

Dus wat bedoel je met: "kijk hier dan ook eens"?

Overigens is dat overzicht ook geen ultieme waarheid, kijk maar eens naar het grote aantal vraagtekens.

Maar ik denk dat het geen nut heeft argumenten aan te dragen in een discussie gedomineerd door "believers".

De eerste functie van een OS is data zodanig opslaan dat het beschikbaar blijft. En daar had NTFS in de genoemde tijd een voorsprong. En op andere vlakken dus NOG STEEDS.

Met de huidige snelle processoren is het erg jammer dat compressie niet ondersteund wordt; zo is Reiser4 bijv. met compressie ook qua performance heer en meester; zie http://linux.50webs.org/resources/fs-benchmarks.htm

[Reactie gewijzigd door pinockio op 26 juli 2024 16:11]

[user109731]

Wat me opvalt is dat Linux qua filesystem-mogelijkheden altijd wat achterloopt op Windows (nofi). Zoals genoemd: transparante compressie.

Het zekere weet ik er ook niet van, maar de reden daarvoor is denk ik dat in de Unix-filosofie compressie niet op fs-niveau maar iets hoger gedaan word. Het fs moet bestanden opslaan.

Verder is het denk ik Windows dat achterloopt op fs-gebied. In de verschillende Unix-kernels zie je tegenwoordig allerlei leuke filesystems opkomen. Reiser4, btrfs en vooral ZFS lopen al voor op NTFS, en dan heb je nog de clustered-filesystems als OCFS. In de Windows-wereld blijft het echter stil, ik vraag me af of we van MS nog een antwoord hierop kunnen verwachten of dat ze vasthouden aan NTFS

[Reactie gewijzigd door user109731 op 26 juli 2024 16:11]

[Verwijderd]

En NTFS heeft ook een hoop onvolmaaktheden. Als je een bestand met bepaalde rechten ergens anders naartoe kopieert is het mij niet helemaal duidelijk wat er vervolgens allemaal gaat gebeuren. Als je een bestand bijvoorbeeld wilt opschonen wat rechten betreft moet je het even naar een FAT- drive kopieren en weer terugzetten. Vreemde omweg, maar wel makkelijk voor een niet-admin.

[axis]

RTFM als je een file kopieert erft ie de rechten van de nieuwe parent.. als je een file moved, houd ie de oude ACL. (althans, dat staat in de win2000 boeken). Heb al sinds NT4 volgens mij geen FAT partitie meer gezien, behalve op een usb stick

[Lennie]

Dit ligt geheel aan de util die gebruikt voor het kopieren.

[pmeter]

Aha. Weet iemand wat Total Commander hiermee doet?

[Verwijderd]

Iedere kopieer util kan uiteraard zelf nog eens de rechten aanpassen op de bestanden die het gekopieert heeft. (Voor zover de user daar de rechten toe heeft).

Dat heeft niets met het filesysteem te maken.

[Rinzwind]

Voor de snelle reageerders. NTFS heeft een uitgebreid rechten model.
Full Control
Traverse folder / execute file
List folder / read data
Read attributes
Read extended attributes
Create files / write data
Create folders / append data
Write attributes
Write extended attributes
Delete subfolders and files
Delete
Read permissions
Change permissions
Take ownership

Allow / Deny

Waarbij rechten kunnen overerven van hogere mappen.
Waarbij gebruikers in één of meer groepen kunnen voorkomen.

Dit biedt uitgebreide mogelijkheden om rechten gedetailleerd in te stellen. Het kan ook een puinhoop opleveren, maar dat heb je met mogelijkheden

En dit werkt over het hele netwerk via een domein.

edit reactie op _Thanatos_

[Reactie gewijzigd door Rinzwind op 26 juli 2024 16:11]

[418O2]

Waarschijnlijk zal het proces van overstappen van ext3 naar ext4 minstens zo lang duren als dat van ext2 naar ext3.

en hoe lang duurde dat ?

[Verwijderd]

Dat ging eigenlijk heel erg snel. ext3 = ext2 met journaling support. Verder was het volledig compatibel.

[borft]

nog sterker, je kunt een ext3 fs gewoon als ext2 mounten. Handig als je een middeleeuwse kernel hebt met alleen ext2 support (of bv een mac of een windows pc die geen ext3 kan).

[Lennie]

Van ext3 kun je wel ext4 maken, maar als je eenmaal nieuwe bestanden hebt aangemaakt kun je het niet meer als ext3 mounten.

Andere interresante features:
- online defragmentation
- men was bezig met snellere file system check (maar ik zie het niet bij de features staan): http://kerneltrap.org/Linux/Improving_fsck_Speeds_in_ext4 lijkt me niet onhandig, met zulke grootte bestandssystemen.

[dtech]

Volgens mij kan ext3 op dezelfde manier ook ext4 mounten, maar ik weet het niet 100% zeker.

[Verwijderd]

Volgens mij ging het in het artikel niet over het technische proces, maar over de tijd die het in beslag nam voordat het gros van de systemen over was op ext3.

[Verwijderd]

NTFS rechten via FAT kwijtspelen, doe ik al een poos (zelfs als admin)
Ik maak op de meeste file-servers een kleine partitie (3 a 4 GB) FAT32 aan, om enerzijds wat installatiedata voor mezelf op te zetten, en eventueel om een hoop rechten kwijt te spelen via copy over die FAT32 partitie...

Is niet elegant, maar vaak wel een stuk sneller dan rechten overnemen en zaken terug recht te zetten...

[TaraWij]

Een shell extentie toevoegen lijkt me hier een nog snellere optie voor, moet gemakkelijk kunnen met de commando's takeown en cacls.