Opvolger ext3-bestandssysteem toegevoegd aan testkernel

Sinds jaar en dag is ext3 een van de populairste bestandssystemen op Linux-systemen. Met het groeien van de capaciteit van harde schijven, kwamen er echter ook vragen of ext3 nog wel voldeed aan de opslageisen van de 21e eeuw. Met deze vragen in het achterhoofd is ext4 ontwikkeld, waarover wij begin juli al eens schreven, en de eerste bruikbare testversie bevindt zich sinds enkele dagen in release candidate 1 van versie 2.6.19-mm van de Linux-kernel. Ext4 ondersteunt partities met een maximale grootte van 1024 petabytes. Verder heeft het nieuwe bestandssysteem support aan boord voor 'extent file writing'. Dit houdt in dat wanneer toevoegingen aan een bestand worden weggeschreven naar de harde schijf, deze achter het oorspronkelijke bestand worden geplaatst. Hierdoor neemt bestandsfragmentatie nog verder af en kan een hogere performance behaald worden. Ext4 is gedeeltelijk compatibel met ext3: het is mogelijk om ext4-partities te mounten als ext3, maar dan kan er geen gebruikgemaakt worden van de nieuwe ext4-features. Naar verwachting zal ext4 binnen zes tot negen maanden klaar zijn voor het echte werk in productiesystemen.

Reacties (67)

[Verwijderd]

Ik denk dat het eerder tijd word voor een modern filesystem dat plug-and-play op elk besturingsysteem te lezen én te schrijven is!

[moser]

De documentatie van ReiserFS, ext3,... is allemaal beschikbaar.
Microsoft heeft het maar te implementeren en je hebthet bestandssysteem dat je wil.

FAT is verouderd en NTFS is zo gesloten dat je enkel aan het werk kan met reverse engineering.

[Diago]

http://sourceforge.net/projects/ext2fsd

ext2 FS lezen en schrijven vanuit WXP
ext3 FS voorlopig alleen nog lezen vanuit WXP

[bassekeNL]

Ikzelf gebruik deze onder windows:
http://fs-driver.org/

Ik dual boot, en zo heb ik een ext3 partitie die ik zowel onder linux als windows kan lezen en schrijven.

Onder windows wordt hij benaderd als een ext2, maar 3 is identiek aan 2 behalve dat er een journal aan toegevoegd is. Onder windows gebruik ik de journaling dus niet.

[PrinsEdje80]

Voor mensen die LVM2 gebruiken en alsnog hun bestanden van linux willen lezen (schrijven gaat nog niet): http://www.chrysocome.net/explore2fs

[F_J_K]

Ik kan me voorstellen dat MS graag iets van leestoegang zou bieden (itt misschien schrijftoegang).

De documentatie mag dan wel beschikbaar zijn, MS en andere partijen kunnen het - zoals ik het zie - niet zomaar gebruiken omdat dat wordt verboden in de licenties.

Bij mijn beste weten zijn ReiserFS en ext3 niet licentievrij (afaik is ext3 GPL en heeft ReiserFS een eigen licentie obv GPL). Dat betekent dat alle bedrijven die er voor kiezen hun software niet opensource te maken (hun goed recht), door deze GPL er niets mee kunnen.

Wel zijn er addins voor Windows die het mogelijk maken ext* te lezen {edit: zie ook KoeNijn hieronder, MS helpt hier zelfs aan mee}. Maar doordat de licentie (vanuit het oogpunt van MS) te restrictief is kan MS er niets mee in het OS zelf.

[pfismvg]

Wat een onzin. GPL betekent hoogstens dat de driver voor dit bestandsysteem ook onder een GPL licentie moet worden uitgebracht. En als voordeel staat daar weer tegenover dat Microsoft een groot gedeelte van de huidige linux code zo kan gebruiken als basis voor de driver.

[merethan]

GPL gelt alleen maar voor de CODE!

GPL heeft niets te doen met de WERKING!
dwz hoe het werkt mag iedereen weten en gebruiken.

[brainball]

er is een wereld van verschil tussen een windows en linux driver. Ik betwijfel of je veel code can copieren van de een naar de ander.

[Gerco]

Er is niemand die Microsoft tegenhoud om ext3-4 bestandssystemen te lezen en schrijven. Microsoft houd wel anderen tegen om zijn bestandssystemen te lezen en schrijven.

Je moet hiervoor dus microsoft aanspreken en niemand anders. Bestandssystemen zijn er genoeg, alleen Microsoft weigert ze te ondersteunen.

[Verwijderd]

Je moet hiervoor dus microsoft aanspreken en niemand anders. Bestandssystemen zijn er genoeg, alleen Microsoft weigert ze te ondersteunen.

'Weigert'?
Wat een onzin.
Je zegt het zelf, bestandssystemen zijn er genoeg. Als je ze allemaal moet ondersteunen, ben je nog wel even zoet.
Waarom zou je uberhaupt ext willen ondersteunen? Alleen linux gebruikt dat.
Apple heeft weer z'n eigen formaat, en BSD ook, etc etc.

Windows biedt de mogelijkheid om een driver voor ieder bestandssysteem te schrijven, dus als je wilt, heb je zo die ondersteuning ingebouwd... als dat al niet door iemand anders gedaan is.

Ik zie niet in waarom Microsoft dat zelf zou moeten doen. Daar is gewoon praktisch geen vraag naar vanuit de markt. Economisch gezien dus totaal niet interessant om dat te gaan doen.

[Blokker_1999]

Als Windows op Ext3 zou draaien zou ik onmiddelijk al mijn partities omzetten. Waarom?

- Ext3 fragmenteerd een stuk minder dan NTFS/FAT.
- Ext3 komt met journaling, risicobeperking op gebied van beschadigde bestanden bij een crash.

[Olaf van der Spek]

- Ext3 komt met journaling, risicobeperking op gebied van beschadigde bestanden bij een crash.

Dat geldt ook voor NTFS.

[zalazar]

Dat dat ook voor NTFS geldt klopt inderdaad.
Maar vanaf Windows 2003/XP is dit pas volwassen. Als je in NT4/2000 een diskcheck hebt op een disk van bijv. 200 GB dan kan je de rest van de dag wat anders gaan doen.

[darkfader]

Ze hoeven het niet eens zelf te implementeren. Het zou al leuk zijn als Windows een bestandssysteem automatisch detecteerd en doorverwijst naar een website waar de de driver kunt downloaden.

[smokalot]

om dat te kunnen doen moet je toch echt de kernels van alle OSen aanpassen om het te ondersteunen, en dan zul jij niet verder komen dan linux, ReactOS en *BSD. Voor de rest heb je toch echt Apple en Microsoft nodig, en vooral laatstgenoemde verliest daar alleen maar marktaandeel aan.

[Verwijderd]

Fout de kernels hoeven niet aan gepast worden bij MS windows. Zie http://www.microsoft.com/whdc/DevTools/IFSKit/default.mspx. Met deze kit is een ext2 driver gemaakt waardoor de ext2/3 partities net zo gewoon door elke applicatie te benaderen zijn als een ntfs/fat partitie.

Ook bij Apple is het ook mogelijk om ext2/3 partities te mounten met een fsdrivertje zie http://sourceforge.net/projects/ext2fsx .

@martijnvanegdom:
Klopt niet, Apple kan alleen overweg met UFS, HFS, HFS+, NTFS(readonly) en FAT. En nog wat cd/dvd/netwerk fsjes.

[VNA9216]

maar dan moet je het wel eerst installeren en is het dus eigenlijk geen plug en play meer he?

[martijnvanegdom]

Apple kan prima overweg met vrijwel alle formats.

[bstard]

Een bestandsysteem is te afhankelijk van de omgeving, en het doel van de host om een universeel FS te maken. Het kan wel natuurlijk, maar dan lever je prestatie in. Zover zijn de IO snelheden nog niet.

[Daenney]

daar heb je Samba/CIFS voor

[alt-92]

CIFS is een protocol om over netwerk cross-platform een filesystem te kunnen gebruiken.
Daar kan je je HD niet mee formatteren ofzo.

[mae-t.net]

Jij bedoelt vast niet elk OS, jij bedoelt gewoon windows. En daar bestaat die feature al lang: Windows kent IFS, waarmee je elk bestandssysteem waar een driver voor bestaat, gewoon kan gebruiken. Voor ext2 bestaan deze drivers, en vast ook wel voor ext3.

[wvd_vegt]

Iemand enig idee hoeveel bestandssystemen er ondertussen zijn voor *nix? Als ik de discussie lees is er voor iedereen & voor elke toepassing wat geschikts.

Ben het dus roerend eens met de eerste poster!

[Verwijderd]

http://en.wikipedia.org/wiki/List_of_file_systems
http://en.wikipedia.org/wiki/Filesystem

[Snake]

Een waardig concurent voor ReiserFS?
Wat zijn dan nog de voordelen van ReiserFS t.o.v. ext3?

[dtech]

performance (oa bij kleine bestanden, RFS is een factor 10 sneller dan ext2/3 bij bestanden lager dan 4KB, lijkt misschien niet super handig, totdat je je realiseert dat een groot deel van de web en mail bestanden kleiner dan 4KB zijn.)

[Ronald]

Precies de reden dat ik Reiser draai is de prestaties met kleine bestanden. Maildirretjes enzo

Prestaties op grote bestanden zijn overigens zeker niet slecht op reiser....

* Ronald maakt zich erg zorgen om de toekomst van Reiser...

[dronkert]

"nitenite maakt zich erg zorgen om de toekomst van Reiser..."

Zowel FS als Hans dreigen op een zijspoor te komen dezer dagen.

[golfdiesel]

http://yro.slashdot.org/yro/06/10/11/0142216.shtml?tid=123
dat kan je wel zeggen.
Als het waar is dan zal in ieder geval de naam wel veranderd moeten worden...

[dmantione]

* De makers van de ext-systemen maken Unix-bestandssysteem.
* De makers van Reiserfs proberen verder te denken dan Unix.


Ext* implementeert alleen wat noodzakelijk is voor Unix. Een fsck begon extreem lang te duren, dus implementeerde men journalisering. Op dit moment wordt 8TB wat krap, dus bouwt men ondersteuning in voor grote schijven. Enzovoorts.

Reiserfs was de eerste die journalisering ondersteunde, wie niet te lang wou wachten gebruikte Reiser. Het is de enige met focus op kleine bestanden, dus als je veel kleine bestanden op schrijf hebt, neem je Reiser. Reiserfs probeert nu verder te innoveren met metadata en ACID-functionaliteit. Met metadata kan je desktopzoekfuncties bouwen met een zoektijd van 0 seconden. Met de ACID-functies kan je een database bouwen zonder eigen speciale dataopslag.

Het is dus met name de filosofie achter de systemen die verschilt, en die uit zich in de functionaliteit.

[Verwijderd]

Reiserfs was de eerste die journalisering ondersteunde, wie niet te lang wou wachten gebruikte Reiser.

Volgens mij was XFS eerder met een goed lopend Journalized FS dan Reiser met toendertijd een prototype genaamd TreeFS.

[BartOtten]

Als Reiser een makkelijk man was geweest dan denk ik dat tegenwoordig iedereen aan ReiserFS of zelfs Reiser4 zou hangen. Jammer dat het zo gelopen is

[Olaf van der Spek]

Wat zijn dan nog de voordelen van ReiserFS t.o.v. ext3?

Support voor meta-data dacht ik.

[H@rry]

ReiserFS is een journaling File System. Het heeft volgens mij net als het WinFS een database achtige opbouw.

[Olaf van der Spek]

ReiserFS is een journaling File System.

Dat is ext3 ook hoor.

[Countess]

voornamelijk betere preformance.

[i-chat]

tov ext3 nog net zo veel als voorheen,
tov ext4 echter een stuk minder.

[Verwijderd]

Ik heb helaas het gevoel dat er teveel naar compatiliteit gekeken wordt.

Ik zie geen enkele reden waarom ext4 compatible moet zijn met ext2 en ext3. In mijn ogen doe je dan connessies in het nieuwe file system.

In deze link zie je nadelen al van ext3 (door de conssessies) http://en.wikipedia.org/wiki/Ext3#Disadvantages

Aangezien linux in de kernel alle oude file systems ondersteund zal een geheel nieuw filesystem ook geen probleem zijn. Ik gebruik zelf xfs/reiserfs en ext3. Vooral de eerste 2.

<mijn fstab>
/dev/sdb1 / reiserfs acl,user_xattr 1 1
/dev/sdb2 /data/A reiserfs defaults 1 2
/dev/sdb6 /data/B reiserfs defaults 1 2
/dev/sdc1 /dv xfs defaults 1 2
/dev/sdb5 /home ext3 defaults 1 2
/dev/sda1 /windows/C ntfs ro,users,gid=users,umask=0002,nls=utf8 0 0
/dev/sda3 /windows/D vfat users,gid=users,umask=0002,utf8=true 0 0
</my fstab>

Vijf file systems op een systeem. Performance technisch waarschijnlijk niet het beste idee, maar het werkt al jaren goed!


Het is geen probleem om ze langs elkaar te gebruiken. In migratie kun je dmv een tar de data overzetten naar een nieuwe partitie. Of neemt iemnd liever het risico om de infomatie te converteren naar ext4? (Als dit laatste fout gaat ben je zonder back-up de data kwijt).

Een goede beschrijving van Linux Journaling file systems:
http://linuxgazette.net/issue55/florido.html

[LauPro]

Je raakt hier een kritisch punt. Dit is al decennia een groot discussiepunt, binnen de OS-wereld zijn er twee kampen:
- Voor backwards compatibility
- Tegen backwards compatibility

De reden om voor te zijn is dat je hiermee de software gebruiksvriendelijke maakt, als men een nieuwe versie installeert van een distributie en daarin zit een nieuwe versie van een FS dat niet compatibel is met de vorige dan is er een probleem. Er zal dan op dat moment een conversieprogramma moeten worden gestart. Voor zover ik weet is er binnen de OS-wereld nog nooit 1 filesystemconversieprogramma gemaakt waarvan de maker 100% garantie heeft kunnen geven dat dit niet kan lijden tot gegevensverlies. Dus dit is het grote probleem, het converteren van een FS is noodzakelijk, maar lastig te implementeren omdat er zoveel factoren zijn. LVM kan ervoor zorgen dat het makkelijker is maar als een harddisk maar 1 partitie heeft voor de root is het knap lastig.

Echter zorgt het aanhouden van die compatibility voor vertraging in innovatie. Stel dat er om een of andere reden nog steeds FAT32 moet worden geïnstalleerd dan zal dat grote problemen met zich meebrengen aangaande het beheren van rechten. Dus het liefst zegt een ontwikkelaar: we maken een fork en kijken naar de toekomst en niet naar het heden/verleden.

Dat is een mooie instelling, echter zal het product op zichzelf dan wel aanzienlijke voordelen moeten bieden. Je zult moeten bewijzen dat je product het waard is om een conversie uit te voeren of anderzijds een migratie. Hoe dan ook het vraagt om aanpassing van de gebruiker en niet iedereen heeft daar tijd voor/zin in.

[_JGC_]

Het is maar net hoe je het gaat ontwikkelen. Als je een filesystem hebt wat gewoon niet goed ontworpen is, gooi je dat aan de kant en maak je iets nieuws. Als de basis van je filesystem goed is, kan je erop verder bouwen. Ext3 is een goed systeem, maar heeft hier en daar een paar tekortkomingen die op te lossen zijn. Je gaat niet ext4 bouwen die compleet incompatible is met ext2 en ext3, dan kan je beter je tijd in projecten zoals XFS or ReiserFS steken.

Zie GStreamer, ze hebben 0.6, 0.8 en 0.10, allemaal incompatible met elkaar. 0.6 software kreeg je met wat 0.6->0.8 versienummer aanpassingen in de configure scripts nog wel aan de praat met 0.8, maar 0.10 hebben ze de hele boel van de grond af opnieuw gebouwd, waarin alleen het basis idee van GStreamer is blijven bestaan: een bak met input, filter en output elementen die je aanelkaar kunt hangen en die samen je multimedia moeten doen. Verder is er in 0.10 geen spaan heelgelaten van de API die 0.6 en 0.8 had. Reden hiervoor: 0.8 was gewoon puinruimwerk en was in het begin al slecht ontworpen, dat knap je niet zo maar even op zonder alles te slopen.

[Olaf van der Spek]

als men een nieuwe versie installeert van een distributie en daarin zit een nieuwe versie van een FS dat niet compatibel is met de vorige dan is er een probleem.

Want?
Waarom zou die nieuwe distributie niet zowel de nieuwe als de oude versie van het FS kunnen ondersteunen?
Dan kunnen oude installaties gewoon verdergaan met het oude FS en nieuwe installaties kunnen beginnen met het nieuwe (niet-compatible) FS.

[LauPro]

Wat is dan nog de reden om die nieuwe versie te installeren? Het gaat je er juist om dat je ook de laatste versie van het FS krijgt, en dat kan nu eenmaal reden tot upgraden geweest zijn.

[2_05]

Wie gaat testen of ext4 de maximale groote van 1024 petabytes wel aan kan?

[Verwijderd]

Dat is wel mogelijk hoor..er zijn 35 Petabyte storage systemen

maar on topic :

NTFS 5 kan tot 16 Exabyte geloof ik en SUN ZFS kan tot zetabytes aan... (resp. 64 en 128 bits addressing)

Het probleem met deze dingen is dat het onmogelijk lang duurt om share properties op zoeen disk te zetten met windows..of iets simpels als "rechtermuis / properties" dat duurt dagen.... nog maar niet te spreken over Terabyte filesystemen recoveren na een chrash..dat kan weken duren...

[Olaf van der Spek]

Ik meld me aan als vrijwilliger. Waar kan ik het testmateriaal ophalen?

[TD-er]

Dit houdt in dat wanneer toevoegingen aan een bestand worden weggeschreven naar de harde schijf, deze achter het oorspronkelijke bestand worden geplaatst. Hierdoor neemt bestandsfragmentatie nog verder af en kan een hogere performance behaald worden.

Vreemd dat dat niet in de oudere fs-en zo was dat indien mogelijk dat dat de voorkeur heeft.
Je kunt dit namelijk niet garanderen. Denk bijvoorbeeld eens aan een filesysteem wat vrijwel vol zit. Dan zullen ook de lege stukken achter files beschreven worden en kan je dus een oude file niet verder schrijven direct achter zijn laatste data.
Zeker wanneer je vrij vaak werkt met grote files die je relatief random loopt uit te breiden en te deleten (videobewerking of databases bijvoorbeeld) dan zal je toch gegarandeerd fragmentatie krijgen.

Het beste lijkt mij toch om een soort van variabele blokgrootte te hanteren. Grote blokken (ettelijke MB's) voor grote files en kleine (grote blokken die opgedeeld zijn) blokken voor kleine files en dan krijg je vanzelf dat de overhead van de fragmentatie nauwlijks meer van invloed is op de performance en dan hoef je ook niet meer moeilijk te doen met plek na recent veranderde files te reserveren voor mogelijke uitbreidingen.
Indien een kleine file dan toch groot blijkt te worden kun je die makkelijk nog even uit een "klein blok" halen en in een "groot blok" plaatsen. Doordat het tot dan toe een kleine file was geeft dat (eenmalig) verplaatsen ook niet echt veel overhead.

[Olaf van der Spek]

Het beste lijkt mij toch om een soort van variabele blokgrootte te hanteren.

Als ik naar NTFS kijk is fragmentatie ook nauwelijks een issue. Van ext3 weet ik het eigenlijk niet, maar volgens mij is het daar ook niet zo'n probleem.

Wat ik wel mis is eigenlijk iets als virtual partitioning waardoor ik bijvoorbeeld kan instellen dat alle grote (> 1/2 gbyte) bestanden aan het eind van de disk komen om zo seek time te verminderen voor de andere bestanden.

[golfdiesel]

na een maand of twee moet ik de ntfs schijven toch echt defragmenteren. Ik merk daarna echt een veel betere performance, zeker met opstarten en het openen van grote bestanden.

[YoMarK]

NTFS framentatie geen issue?
NTFS raakt verschrikkelijk gefragmenteerd na verloop van tijd. Een defragger is onmisbaar.

[_JGC_]

NTFS fragmenteert ook als de ziekte. Filesystems op linux fragmenteren ook redelijk, XFS fragmenteert eigenlijk het meeste.

Als ik bij archlinux een paar keer update, krijg ik enorme fragmentatie:
- nieuwe package "database" met 10.000 bestanden wordt uitgepakt en vervangt hierbij de oude bestandjes
- nieuwe software wordt geinstalleerd

Als je dit een paar keer doet, staan van die 10.000 kleine bestandjes weinig meer bijelkaar in de buurt en rammelt je harddisk als een gek. Alhoewel die bestandjes allemaal kleiner dan een kilobyte zijn en het er 10.000 zijn, gaat Reiserfs hier slecht mee om, XFS nog slechter en met ext3 is het nog redelijk te doen. Om het geheel te defragmenteren heb je echter geen vage tools nodig, dat kan het systeem zelf:
cp -a /var/lib/pacman /var/lib/pacman.new
rm -rf /var/lib/pacman
mv /var/lib/pacman.new /var/lib/pacman

De kopieeractie zorgt dat alles achterelkaar komt, vervolgens flikker je de gefragmenteerde zooi weg en zet je de ongefragmenteerde "database" weer terug.

AFAIK is iets soortgelijks op NTFS ook wel te doen, maar het is zo ontzettend omslachtig om je halve systeem te dupliceren en terug te moven, een defragmentatietooltje werkt veel beter.

Voor de mensen die zo gek zijn op reiser4: bovenstaande truc is samengevat in een tooltje "pacman-optimize", welke behalve de bovengenoemde stappen ook eerst md5sums van alle bestanden trekt voor en na het process. Het vreemde met reiser4 is echter dat de md5sums voor en na het uitvoeren van bovenstaande acties altijd verschillen. Super bestandssysteem, echt waar, ik zou het meteen voor al mijn productiemachines inzetten

[MBV]

Ik zat zelf te denken aan een soort van online-defragmentatie: zodra je er iets achter wilt zetten zodra het niet past, zet je eerst de uitbreiding ergens waar het originele bestand vóór past, en daarna kopiëer je het bestand naar die plek toe. Integriteit kan je op die manier garanderen, net zoals caching enzo.

Is er trouwens wel een defrag voor ReiserFS en Ext3? Nooit nodig gehad

Is ZFS (laatst artikel in C'T erover) geen goed alternatief voor Ext3?
Waren er niet al minstens 10 filesystems die beter zijn dan Ext3?

[TD-er]

Dat idee lijkt wel aardig, mits je uitgaat van relatief kleine files.
Ik wil niet een file van een paar GB moeten verplaatsen alleen om te voorkomen dat het gefragmenteerd raakt.
Dan is de overhead van het seeken van de head alweer vrijwel nul.
Kortom fragmenteren is niet erg, mits de losse fragmenten maar niet te klein zijn.

[Superstoned]

wat jij beschrijft is zo'n beetje wat ext3 doet... de meeste bestandssystemen doen dat al. een nieuw bestand word 'ruim' geplaatst (dus met ruimte ervoor en erna) zodat het vergroot kan worden. pas bij een 95% volle schijf zullen bestanden gaan fragmenteren. er zijn natuurlijk nog primitieve bestandssystemen die fragmenteren, zoals NTFS en FAT, maar vrijwel alle andere doen dat maar zo minimaal dat er meestal niet eens defragmentatietools beschikbaar zijn.

ext4 is hoogstens nog IETS slimmer, en zal NOG minder snel fragmenteren, maar eigenlijk maakt het niet zo veel meer uit.

[TD-er]

Mijn punt was niet zozeer dat je ruimte vrij laat voor en na een bestand (waarom trouwens voor?), maar dat je de blok-size zo groot maakt dat zelfs bij 100% gefragmenteerde files het nog vrijwel geen performance-issue meer is.

Simpel getallen voorbeeld:
Stel je schijf kan 10 MB/s doen als max snelheid.
Het zoeken naar een andere sector willekeurig ergens op de schijf kost 10 ms en in die tijd kan er dus niet gelezen worden.
Dus bij een 100% gefragmenteerde file (dus geen enkel blok data staat achter elkaar) met blokgroottes van 100 kB doe je 10ms over het lezen van 1 blok. (1/100sec)
Dus per sec lees je dan gemiddeld gedurende 500ms en wacht je 500 ms op de seek naar de juiste sector. Dus 50% van de tijd sta je te wachten. (gemiddeld 5 MB/s)
Met datablokken van 1 MB lees je dus een datablok per 100 ms en wacht je 10 ms. Dan heb je dus nog maar amper 10% overhead door de fragmentatie. Netto haal je dan zo'n 9,09 MB/s
Met datablokken van 10 MB zal de overhead zo ongeveer 1% zijn bij 100% gefragmenteerde files.

Kortom als je de datablokken maar groot genoeg maakt voor grote files heb je geen last meer van fragmentatie.
Echter grote datablokken wil ook zeggen dat je veel ruimte verliest bij de kleine files (gemiddeld zal zelfs meer dan een half datablok zijn bij grote datablokken).
Dus door voor kleine files een groot datablok op te delen zou je dat kunnen compenseren.

Voor zover ik weet gebruikt in elk geval Ext2 niet dit principe en Ext3 is uit te lezen met een Ext2 driver, dus ik vermoed dat ze dit nog niet gebruiken.

[roy-t]

Super intressante theorie, maar:

als je die kleine bestandjes blokjes laat delen, en je moet bijvoorbeeld 10mb aan kleine bestanden hebben dan moet je (behalve als ze toevallig in het zelfde blok staan) toch weer zo lang seeken.

Je filesysteem werkt dan dus alleen als je grote bestanden hebt (+5MB bijvoorbeeld) Maar vooral bij linux heb je al die kleine prut bestandjes, net als op webservers etc.

Ik zou echter graag mijn 2e hardeschijf zo willen instellen als jij nu voorstelt (2e HD met grote bloksize voor DVDs, muziek en download, en dan 1e HD met kleine bloksize voor windows/linux en installatie van programma's)

Miss dat een HD virtueel gepartitioneerd zou kunnen worden met 60% Grote BlockSize en 40% klein, klein aan het begin van de hd en groot aan het eind, zodat je alles bij elkaar hebt en zowel de voordelen als de nadelen hebt. *dromer modus :z*

[Zwartoog]

Waarom geen ZFS (Zeta Byte fileSystem)? Dit biedt ondersteuning voor het on-the-fly vergroten en verkleinen van het filesystem. Schijnt erg goed in elkaar te zitten.

[kodak]

Vanwege twee hoofdredenen:
1) licentie problemen. Sun heeft ZFS uitgebracht onder een licentie die niet compatible is met GPL. Sun gaat geen tijd steken in verandering en dus moet dat van buitenaf komen, maar dat staat nog in de kinderschoenen.
2) geen boot support. Dat wordt doorgaans niet makkelijk geaccepteerd voor de kernel omdat het een behoorlijke drempel is om er serieus mee te gaan werken.

[BartOtten]

En hoe groot is de ontwikkelgroep?
EN hoe lang gaat het al mee zodat het uitgebreid getest is?
En hoeveel onderhoud tools zijn er?
En hoe gaat het met diskruimte om?

Er zijn wel wat meer vragen die je je moet stellen.

Daarnaast is LVM nu standaard in openSUSE volgens mij dus dat aanpassen van ruimte is dan ook geregeld.

[Olaf van der Spek]

Daarnaast is LVM nu standaard in openSUSE volgens mij dus dat aanpassen van ruimte is dan ook geregeld.

LVM is geen FS. En het FS moet als je LVM gebruikt ook (online) resize ondersteunen.

[Borizz]

Dat kan volgens mij met LVM ook al..

[Verwijderd]

Ik begin me zo langzamerhand erg te irriteren aan het zomaar wegmodden van posts als overbodig. Dat gebeurt veel te vaak.

[kamerplant]

Zet in je instellingen dan aan dat het minimum niveau wat jij wilt zien -1 is, dan heb je geen last van de zelfcencuur

[Verwijderd]

Ik denk dat deze opvolger een goeie kans maakt.

1 van de belangrijkste mensen die aan ReiserFS heeft gewerkt is beschuldigd van Moord. Novell heeft al aangegeven door te gaan met ext3 waarschijnlijk omdat de toekomst van ReiserFS onzeker is.

http://www.webwereld.nl/a...ven-reiserfs-in-suse.html

[Verwijderd]

Jongens wat maak jullie niet te druk joh Ongeacht wat je nu neemt NTFS of ext3 of straks ext4 - tis allemaal maar een trade off tov de minste ellende tov van bepaalde eisen. Anders gezegd; die hardeschijven ansich zijn gewoon ruk. Als we straks solidstate schijven hebben enzo - wordt het vast weer anders.

Maar euhm voor een ieder die NTFS read/write wil mounten zonder gezeur - FUSE met ntfs-ng werkt als een tierelier