Linux-ontwikkelaars werken aan ext4-bestandssysteem

Twee weken geleden is op LWN.net een artikel verschenen waarin gemeld werd dat patches waren geschreven waarmee het bestandssysteem ext3 voorzien zou kunnen worden van support voor grote partities. Ext3 wordt onder meer in veel Linux-distributies gebruikt als 'file system of choice' vanwege zijn betrouwbaarheid. Het bestandssysteem heeft echter als voornaamste nadeel dat slechts gewerkt kan worden met partities die maximaal 8TB groot zijn. Dit is voor de meeste thuisgebruikers geen probleem, maar voor bedrijven wordt dit veel vaker een beperkende factor. De genoemde maximumgrootte van 8TB heeft twee oorzaken. Er wordt gebruikgemaakt van signed 32bits bloknummers binnen het file system. De ext3-code kan slechts twee gigablokken aan, wat betekent dat met een blokgrootte van 4KB er maximaal 8TB aan ruimte is. Door van signed naar unsigned bloknummers te switchen kan dit 16TB worden; dat is echter geen oplossing voor de lange termijn.

Het tweede probleem is te vinden in de manier waarop ext3 bijhoudt welke blokken bij een bepaald bestand horen. De inodestructuur van ext3 bevat een array die bestaat uit 15 32bits pointers. De eerste 12 pointers verwijzen naar de eerste 12 blokken van het bestand, voldoende voor een bestand van 48KB bij een blokgrootte van 4KB. Wanneer een bestand groter wordt dan 48KB wordt een 'indirect block' gecreëerd: een extra array met 1024 pointers naar bestandsblokken. De 13e pointer uit de eerste array verwijst naar dit indirecte blok en de 14e en 15e verwijzen op hun beurt weer naar 'double indirect blocks': pointers die verwijzen naar indirecte blokken met pointers. Hierdoor kunnen bestanden gemaakt worden met een grootte van 4TB. Dit systeem werkt voor kleine bestanden erg efficiënt, naarmate bestanden groter worden, wordt het pointerbeheer een kostbare aangelegenheid vanwege de overhead.

Een oplossing voor deze problemen is gevonden in een patch die 48bits support aan ext3 toevoegt waardoor de maximale partitiegrootte 1024PB (1.048.576TB) wordt. Het belangrijkste onderdeel van deze patch is de ondersteuning voor 'extents'. Een extent is een groep blokken die zowel binnen de bestandsstructuur als op fysiek niveau logisch achter elkaar zijn geplaatst. Door de bestandsstructuur op te slaan als extent hoeft dus minder metadata worden opgeslagen, omdat één extent verwijst naar meerdere blokken, iets waar voorheen meerdere pointers nodig waren. Wanneer ext3 met deze patch gebruikt wordt, zullen oude bestanden op de conventionele wijze behandeld worden. Nieuwe bestanden worden op de nieuwe manier opgeslagen. Vanuit de kernelgemeenschap, waar de ext3-drivers ontwikkeld worden, is positief gereageerd. Wel is de vraag gesteld of ext3 nog wel ext3 moet heten. Het toevoegen van de patches heeft namelijk veel vragen opgeleverd.

Zo is opgemerkt dat het verder ontwikkelen van het stabiele ext3 voor instabiliteit kan zorgen, wat mogelijk tot bestandsverlies zou kunnen leiden. Verder betekent het invoeren van het bijgewerkte ext3 dat nieuw gemaakte bestanden niet gelezen kunnen worden door de oude ext3-driver, omdat die niet kan omgaan met de nieuwe bestandsstructuur. Dat zorgt voor onduidelijkheid bij eindgebruikers die niet zullen begrijpen dat ext3 niet overal hetzelfde is. Tot slot zorgt het invoeren van de huidige patch voor extra complexiteit in de ext3-code, doordat de nieuwe features allerlei conditionele checks met zich meebrengen. Hierom is besloten door de maintainers van ext een nieuw file system te creëren: ext3dev. Deze wordt voorzien van de genoemde patches en zal verder ontwikkeld worden. Het huidige ext3 zal alleen nog van bugfixes voorzien worden. Wanneer ext3dev voldoende stabiel is, zal deze omgedoopt worden naar ext4 waarna met de uitrol begonnen kan worden.

Reacties (73)

[Verwijderd]

<snip>
Jij als gebruiker krijgt nooit te maken met Linux, dus waarom zouden ze zich daarop richten. Of richt Microsoft hun kernel32.dll wel op gebruikers?
<unsnip>

Fout.
Juist als gebruiker krijg je hier wel mee te maken vroeger of later.
Kijk, linux wordt op dit moment gebruikt op de meeste grote sites op het internet.
Voor bedrijven zoals Oracle en IBM is de beperking van EXT3fs een doorn in het oog.
Laat nou zowel Oracle als DB2 hier tegenaan te lopen?
En laten nou beide databases vooral door sites zoals www.bol.com en www.amazon.com gebruikt worden?
En wat dacht je van grote mailservers zoals bij XS4ALL.
Of hotmail.
Deze bestaan uit grote databases met daarachter webends die die database raadplegen.
Of wat dacht je in de toekomst van streaming video providers met tig terabytes aan video?
Zo zijn er nog wel meer voorbeelden denkbaar waar jij als gebruiker indirect mee te maken gaat krijgen in de toekomst.

[Fuzzillogic]

Nou ben ik behoorlijk linux-n00b, maar ik ben in ext3 en ReiserFS 3 nog geen dingen tegengekomen als ecryptie en compressie op file-niveau, zoas Windows dat wel heeft sinds 2000. Zeker encryptie op file-niveau is wenselijk m.i.

En nu wordt hier met ext4 ook weer met geen woord over gerept?..

[dingstje]

Denk hierbij aan de geest van UNIX om één tool één taak te laten doen. Het filesystem heeft als taak het bijhouden van de bestanden op de harde schijf, niet om authenticatie/authorizatie/encryptie te doen. Voor encryptie gebruik je maar GPG. Voor per-user authorisatie kan je grsec gebruiken, authenticatie kan geregeld worden door PAM.

[smokalot]

en je hebt natuurlijk LUKS om driveimages, partities of arrays te encrypten.

Er is idd geen enkele reden om zoiets in je FS te doen.

[Verwijderd]

En ook hier is prima aan gedacht.

Je hebt 3 opties die ik ken. Als je met filesysteem X wil werken maak je op je harddisk een LVM aan en laat je die LVM encrypten. De wat oudere manier was met loopback encryptie toe te passen is eigenlijk niet meer nodig, maar kan nog wel.

Met ReiserFS4 is het zelfs mogelijk om het (via een plugin) direct in het FS te doen, net als LVM dat ook enigsinds doet.

Voor files encrypten pak je gpg zoals eerder vemeld.

Het filesysteem per file encryptie laten afhandelen is onzin. Dat is de taak van het FS. Dat is een bewerking op de file, een stapje hooger.

[Sfynx]

Er is idd geen enkele reden om zoiets in je FS te doen.

Nee elke applicatie zelf z'n encryptie laten doen is handig. Dan beter 1 fantastische implementatie in het file system en je applicaties hoeven niet eens te weten dat het filesystem aan encryptie doet. Je kan zonder problemen je huidige filesystem vervangen door eentje die ook zelf encryptie doet, zonder dat je applicaties herschreven moeten worden om GPG o.i.d. te kunnen praten. Dat is het voordeel. Een filesystem is een filesystem voor je tekstverwerker.

[Fuzzillogic]

Zo denk ik er ook over. Encryptie en compressie moet gewoon transparant gaan. Ik wil niet eerst handmatig mijn OpenDocument bestandjes handmatig decrypten op naar een unencrypted medium omdat OpenOffice.org geen GPG praat.

Files moeten gewoon ecrypted worden met de creditials van de user die ze aanmaakt. Net zoals NTFS.

Op sommige gebieden pakt Windows het toch echt beter aan, m.i.

[Chatslet]

Beetje onzinnig wat hier allemaal wordt geroepen. Volgens de mensen hier is encryptie door het FS totaal overbodig maar ondertussen voorziet het FS onder Linux wel in Quota's en accounting? Kom op wat wil je nou? Moeten dat soort dingen nou wel of niet door het FS gedaan worden? En kom dan niet aan met het ene wel en het andere niet want dan ga je echt een enorme bende krijgen. Ieder programma zijn eigen encryptie die dan vooral totaal verschillend is, laten we dat dan maar doen in de geest van interoperabiliteit.

[lvh]

Encryptie door je filesystem zelf laten afhandelen is gewoon onzin. Je filesystem is een filesystem, geen encryptieprogramma, full stop. Als je zo graag encryptie hebt, bouw dan een transparante layer bovenop je filesystem maar begin ingodsnaam niet aan ext3 zelf te sleutelen...

[dmantione]

Alle ext-bestandssystemen zijn een klassiek Unix-bestandssysteem. Met andere woorden, alles wat Unix wil zo goed mogelijk doen.

Bij ReiserFS probeert men te innoveren, men denkt verder dan Unix. ReiserFS 4 zou encryptie op bestandsniveau mogelijk moeten maken.

[daft_dutch]

Linux maakt gebruik van encryptie doormiddel van Loopback. Je pakt een FS wordt doormiddel van een loopback encrypt/decrypt. De loopback is je virtuele encrypted filesysteem.
Dit is veel makkelijker doordat je zelf kan kiezen wat voor fs je zou willen hebben. En ook welke encryptie je gebruikt.
Met de verschillende FS/encryptie. zijn er al honderden verschillende mogelijke heden.

Encryptie op de partitie zelf is niet gewilt. dit sluit andere (betere) encryptie methodes uit.

[kidde]

Linux heeft al een aantal jaren (ten minste sinds 1999) file-encryptie ter beschikking in de vorm van OpenSSL. Moet wel vanaf de commandline.

Als je eerst de plaintext op een ge-encrypteerde disk opslaat werkt dit prima.

Verder is Microsoft's encryptie per definitie onveilig omdat niemand (buiten MS) de implementatie van het encryptieschema kan controleren. Microsoft heeft in het verleden al backdoors ingebouwd voor de NSA.

[Johnny]

Maar waarom hebben ze er dan oorspronkelijk voor gekozen om signed integers te gebruiken voor de bloknummers? Dat doe je alleen als je een negatieve getallen wil kunnen gebruiken, wat bij bloknummers duidelijk niet aan de orde is.

[SPee]

En waarom gebruiken ze nog 32 bits en niet meer 64 bits
Scheelt ook een stuk denk ik.

[Blokker_1999]

ext3 is al heel wat jaren oud. ext3 is in feite zelfs ext2 waaraan journaling is toegevoegd en het is dan ook nog steeds backwards compatibel met ext2. ext2 stamt dan weer af uit 1993 toen dat 8TB nog enorm ver weg leek.

[n4m3l355]

Ipv 32kbit naar 48kbit geeft al 1024PB. Dan valt wel te verwachten dat men nog even kan doorschalen. Wat ik niet helemaal snap is dat men van 4kb blocks uitgaat. Bij partities van 8Tb van die afmetingen zou ik toch verwachten dat men ook grotere blocks toepast. Volgens mij kan ik bv mijn arrays niet eens onder de 128kb blocks formateren wat dan de mogelijkheid geeft van ipv 8Tb partities 256Tb partities zou geven. Met het oog naar de toekomst lijkt me dat misschien aan de krappe kant maar heden ten dagen lijkt me dat toch wel ruim voldoende.

[dmantione]

Omdat de schijven wel groter worden, maar de bestanden niet. Op een computer staan veel kleine bestanden en weinig grote. 128k-blokken voor bestanden van 500 byte is gruwelijk inefficiënt.

Deze constatering is ook exact de reden achter de ontwikkeling van ReiserFS geweest: een bestandssysteem dat zeer efficiënt is met kleine bestanden, zonder dat dit gevolgen heeft voor de prestaties bij grote bestanden.

[Verwijderd]

Heeft dit niet met snelheid te maken? Hoe ziet de distributie van files er uit qua grootte?

Als er relatief veel kleine files zijn, is het sneller om met kleine files (met de kleinere, 32bit, namen) aan te spreken --- anders moet je binnen die grotere blok weer gaan adresseren wat een extra operatie is, bij lezen en schrijven. Of zit ik ernaast?

[Chatslet]

Grotere bloks zijn niet altijd beter. Als een FS blocks van 32kb heeft en ik schrijf een bestand van 1kb weg dan vult dat bestand een heel blok van 32kb. Werk je dus met veel kleine bestanden dan wil je dus de blocks kleiner houden.

[Frank-L]

Het gebruik van unsigned integers zou je juist zoveel mogelijk moeten beperken in talen als C, omdat ze inherent gevaarlijker zijn dan signed integers. Door default voor normale 'signed' ints te kiezen voorkom je een hele hoop potentiele bugs in je code.

[martijnvanegdom]

Sterker nog, het probleem wat FrankL aanhaald heeft al erg dure bugs opgeleverd, de Ariana 5 raket is er door uit de lucht gevallen..


http://archive.eiffel.com...contract/ariane/page.html

[Verwijderd]

Onzin.

Lees het artikel eens goed. Het probleem is niet welk type variabelen er gebruikt werden, maar dat er een sloppy conversie uitgevoerd werd, die toevallig goed werkte binnen de range van waarden die in de Ariane 4 gebruikt werd.

Slordig programmeer werk, in combinatie met slechte documentatie. (De typische manier van werken in de IT dus.... )

[killercow]

idd, de range die gebruikt werdt in de arianne 4 was pre 2000, en die van de 5 was post 2000, wat dus wel degelijk een behoorlijk verschil in de koers berekening oplevert als je maar 2 digits opslaat. (van t jaar iig).

En mensen maar denken dat de y2k bug nooit bestaan heeft.

[TheekAzzaBreek]

Unsigned integers inherent gevaarlijker? Dat mag je me eens uitleggen.
Ondoordacht mengen van datatypes is natuurlijk link (zie AHBdV), maar dan hebben we het over de sectie stomme fouten. Wat is er gevaarlijk aan het datatype zelf?

[Frank-L]

@dmantione:
Jij hebt het denk ik alleen over simpele increments en decrements. De meeste programma's bevatten ook complexere berekeningen, en dan is vooraf controleren niet meer zo makkelijk. Of wat dacht je van input-variabelen controleren?

En wat dacht je van constructies als: if (a-b > c) ...
Als b>a kan zijn gaat het mis indien het unsigned ints zijn. Natuurlijk is dit dan een domme constructie, het had dan if (a > b+c) ... moeten zijn, maar met signed integers sluit je dit soort fouten gewoon grotendeels uit.

[Frank-L]

Een C of C++ compiler checkt niet op underflows. Maar door unsigned integers te gebruiker kan de programmeur er ook niet meer op checken (bijvoorbeeld met een assert of een if, of de conditie van een while/for-loop).

[VisionMaster]

Ach er zijn altijd nog programmeurs die de optie -Wall aan hebben en zich niets van potentiele problemen aantrekken. Tja... dan krijg je soms nog wel eens onverwachte problemen. Ik kan effe geen voorbeeld bedenken, maar vaak worden tricky conversies wel aangegeven in een warning.

[dmantione]

Dat is onzin, je kunt er niet achteraf op testen, maar een eenvoudige test voordat je verhoogt of verlaagt is geen enkel probleem.

[Koffie]

is besloten door de maintainers van ext een nieuw file system te creëren: ext3dev. Deze wordt voorzien van de genoemde patches en zal verder ontwikkeld worden. Het huidige ext3 zal alleen nog van bugfixes voorzien worden. Wanneer ext3dev voldoende stabiel is, zal deze omgedoopt worden naar ext4 waarna met de uitrol begonnen kan worden.

Wat volgens mij betekend dat een conversie van Ext3 naar Ext4 eigenlijk heel soepel zou moet verlopen.
Convert naar Ext4 in luttle seconden, want je ben op hetzelfde niveau als nu (oude file op originele wijze, nieuwe op de nieuwe wijze).
In de achtergrond kun je dan vervolgens de oude file op nieuwe manier gaan migreren.

[Keiichi]

Waarom niet werken aan goede ondersteuning voor UFS(2)?

een UFS2 fs kan mak 1 YotaByte zijn en bestanden max 512 GigaByte tot 32Petabyte (bron : http://en.wikipedia.org/wiki/Comparison_of_file_systems)

UFS(1) heeft opzich ook al ruimere limieten dan ext2/3 of reiserfs

[burne]

UFS is een ongestandariseerde klerebende. Zo kun je niet met zekerheid zeggen welke exacte variant je onder de kop hebt op het moment dat je het mount. En UFS sluit als BSD-filesystem slecht aan bij de bestaande praktijk van partities en komt met z'n eigen ideeen en terminologie. Leuk voor BSD-mensen, maar de meeste linux-admins hebben geen idee wat het verschil tussen een slice en een partitie is.

[TGEN]

Het feit dat de meeste Linux admins er geen weet van hebben betekent niet dat het slecht is. Slices bieden in principe dezelfde voor- en nadelen als een PC extended partition. Het voordeel is echter wel dat dit portable is over meerdere architecturen. En gezien de eigen ideeen en terminologie, denk niet dat EXT2 ontwikkeld is zonder leentjebuur te spelen bij FFS . Dat het andere richtingen opgaat tijdens verdere ontwikkeling is natuurlijk te voorspellen, maar dat geldt ook voor de bestandssystemen die wel 'goed'(1) werken onder Linux.

(1): Sommige mensen claimen dat ReiserFS bij hun wel betrouwbaar werkt.

[BartOtten]

(als je het wilt uitproberen, doe maar eens een reiserfsck met --rebuild-tree als argument)

In mijn "!man reiserfs" staat dat dat niet erg verstandig is om te gebruiken omdat het een zeer onstabiele functie is met een bijna onmogelijke taak. Blij dat ik die dingen lees omdat ze door experts geschreven zijn.

[frut666]

Hmmm, ik moet zeggen dat ik met groote tevredenheid, zonder problemen productie systemen op ReiserFS draai. En vanwege incompatiabaliteit van de software die ik er op moet draaien, zelfs op een 2.4 kernel (SuSE 9.0)

Het gaat hier om een redelijk belaste DB2 database server, een LDAP server en nog wat WebSphere Portal spul. Nog nooit problemen mee gehad. Zelfs niet toen iemand per ongeluk de stekker eruit trok. Wat mij betreft, werkt ReiserFS gewoon goed en betrouwbaar.

[Sfynx]

Reiser heeft wat corruptieproblemen gekend bij vroege 2.4 kernels, maar is nu een rock solid filesystem dat net zoals ext3 journaling doet. Het is ook erg snel naar mijn ervaring. Ik heb er inderdaad nooit problemen mee gehad. Geen idee wat de maximale pertitiegrootte van dit filesystem is trouwens.

[BartOtten]

Ik heb mijn Reiser nog nooit kapot gekregen terwijl de bak die hier staat (hardwarematig) gigantisch onstabiel is en vaak crashed, niet zelden tijdens transfers. ReiserFS maakt bij de reboot netjes de transactie af of annuleert de boel. Ik ben de grens van 1000 transacties na een crash al lang voorbij gegaan . En tot nu toe nog geen corrupt bestandje gevonden en geen harddisk problemen gehad.

Geen problemen met ReiserFS dus.

edit: En als je deze post op T.net bekijkt zie je dat ik al jaren worstel met storingen (2004)

[BartOtten]

Stel dat je in een ravijn stort. De kans dat je 100 meter opgetrokken kan worden aan een dun koort is nihil. Zeg je dan ook "eigenlijk is het een idiote oplossing laat maar zitten?"

Functies zoals dat hebben de PolarLanders al een tweede leven bezorgd. Functies die nooit gebruikt horen te worden, alleen door experts begrepen worden en van 0% kans een schamele 5% kans maken. Je zou ze maar nodig hebben. Dan is 5% misschien net genoeg.

[Wolfboy]

ReiserFS werkt ook prima, _als_ het werkt.
Met een paar harde resets, reiserfsck en resizereiserfs heb ik in ieder geval al heel wat filesystems het hoekje om zien gaan (alle 3 afzonderlijk)

ReiserFS is leuk voor thuisgebruik maar nog echt niet volwassen, en Reiser4 daar zal ik het maar niet over hebben.

_{disclaimer: ik draai zelf voornamelijk ReiserFS, het is wel lekker snel en zo gebruik ik die backups nog es}

Aan bovenstaande heren, resize_reiserfs heeft vorige week nog een heel filesystem van me richting /dev/null geholpen, een aantal superblocks fubar en direct was de hele journal het hoekje om, resultaat filesystem zonder journal (als je het wilt uitproberen, doe maar eens een reiserfsck met --rebuild-tree als argument)

[Verwijderd]

@Xarenion
Het is een functie. Als je die functie aanbiedt moet die gewoon werken. Zo niet, moet je hem niet aanbieden.

Je kan je trouwens afvragen waarom men "een onstabiele functie met een vrijwel onmogelijke taak" deel laat uitmaken van een productie filesysteem. Blijkbaar is de functie dus onmisbaar.

Leuk dat je de handleiding leest maar als ik in een handleiding van een bestandsysteem lees dat een functie onstabiel is en tot dataverlies kan leiden is het bestandsysteem in mijn ogen niet rijp voor grootschalige toepassing.

[Wolfboy]

@Xarenion: Dat klopt, het is niet stabiel, maar als je ReiserFS filesystem corrupt is (wat naar mijn ervaring nog regelmatig voorkomt) heb je vaak geen andere keuze.
Mounten wil niet meer, alle andere repair functies doen niets meer, de enige optie is rebuild-tree, en dat is inderdaad nogal dodelijk voor je bestandsstructuur (let wel, de bestanden blijven bestaan, ze hebben alleen geen namen en mapstructuur meer)

[ppl]

De huidige manier van partitioneren op de x86 (op een Sun SPARCstation 4 & 5 zul je die echt niet tegenkomen) bestaat ook niet zo lang. UFS borduurt voort op de UNIX manier van partitioneren en bestaat dus al heel wat langer. De vraag is dan ook eerder waarom ze in hemelsnaam een ander systeem zijn gaan gebruiken die eigenlijk ook nog eens onlogischer is. Hierdoor moet je met een BSD smaak of ieder ander systeem tegenwoordig op een x86 machine dat systeem ook aanhouden. Dat houdt dus in dat men wel van slices gebruik moet maken omdat ze met BSD varianten nog steeds die oude UNIX manier aanhouden. Die slice is dus puur een emulatie manier en daar binnen wordt gewoon de oude UNIX manier gehanteerd. Het is dus de x86 die met haar eigen ideeen en terminologie aankomt, niet andersom.

Dit zijn zaken die je zeker wel als Linux admin behoort te weten. Vaak worden die admins namelijk ook in de UNIX hoek gedrukt. Kom je daar een Sun SPARCstation 4 tegen, dan kun je die ook niet zo gaan partitioneren als een x86 machine, ook niet als je er Debian Linux opzet
Die oude Sun machines gaan namelijk ook van die oude UNIX partitionering uit (daar heb je dus geen slices als je gebruik maakt van OpenBSD of Debian Linux). Je behoort als admin zulk soort zaken gewoon te weten.

[Verwijderd]

als je partitioneert op een andere manier dan op pc's gebruikelijk is, kan je dus niet compatible zijn met windows, en veel linux gebruikers willen toch een dual-boot systeem of een bestaande pc overzetten naar linux.
Maar volgens mij is dit allemaal off-topic, d emanier van partitioneren en het op de partities gezette filesystem hebben niet direct met elkaarte maken, tenzij er een filesystem is wat alleen werkt met een bepaald type partitionering natuurlijk, zoals dat in windows het geval is.

[Verwijderd]

Gaat Ext4 nou ook nog sneller worden ?

[Countess]

minder overhead is natuurlijk altijd sneller.
maar of het echt veel zal schelen betwijfel ik.

[_Thanatos_]

Als je meer snelheid wilt, is het denk ik makkelijker om een snellere CPU in je computer te gooien

[Skit3000]

Het belangrijkste onderdeel van deze patch is de ondersteuning voor 'extents'. Een extent is een groep blokken die zowel binnen de bestandsstructuur als op fysiek niveau logisch achter elkaar zijn geplaatst.

Krijg je dan niet meer fragmentatie van je bestanden als het in grote achtereenvolgende blokken staat en je gaat veel bestanden met onbepaalde bestandsgrootte wissen en schrijven?

[Zenix]

mooi, zo hou je het tenminste overzichtelijk. In tegenstelling tot sommige andere software fabrikanten.

[Z-Dragon]

Waar blijft de algemene ondersteuning voor Reiser 4?

[Daimanta]

As of May 11, 2006, Reiser4 still has not been merged into the mainline Linux kernel due to coding style issues and consequently is not supported on many Linux distributions;

Bron: Wikipedia.org

[Gert]

Daar word je toch moe van, al die koppige ontwikkelaars die het maar altijd beter weten.

[BartOtten]

Het is onwaar wat jij zegt. Daar word je niet moe van.

[voodooless]

Reiserfs4 is echt meilen verder vooruit op ext3, en vermoedelijk ook ext4, dat wel lijkt te bestaan uit een berg patches.

Omdat het zo complex is heeft het ook tijd nodig om stabiel te worden. Helaas komen er dan wat koppige gasten bij die de boel vertragen. Oerzonde als je er zo lang aan gewerkt hebt.

Ik gebruik al jaren geen ext3 meer. Heb er al een paar keer slechte ervaringen mee gehad (disk leeg na reboot enzo..). Reiser 3 is ihmo het betere fs, en heb daar never nooit een enkel probleem mee gehad.

[psyBSD]

Een fs dat moet 'stabiliseren' is echt geen mijlen vooruit op een fs dat netjes zijn werk doet en al jaren staat voor betrouwbaarheid.

[BartOtten]

Wel als de ontwikkelaars gewoon voor op hun website hebben staan dat het FS nog moet uitbalanceren. Als je een FS maakt die in 1x goed werkt zoals jij wilt dan is het een "Hello World"-principe.

ReiserFS4 is nu denk ik wel compleet uitgebalanceerd en nu zijn ze volgens mij alleen nog maar aan het tweaken, tweaken en nog eens tweaken.

Als een machine in een fabriek vervangen wordt voor een betere dan zal die betere de eerste weken/maanden ook nog kuren vertonen. Dan zegt toch ook niemand: "Die vorige die was al jaren stabiel dus de nieuwe is niet superieur."

[Verwijderd]

Sorry hoor, maar linux is geschikt voor simpel consumenten gebruik en voor de enterprise... dan denk je toch niet dat ze een onstabiel FS gaan integreren in 't OS? Je doet alsof bugjes geen enkel punt zijn, maar corrupte data door een nog niet 100% stabiel FS is niet recht te lullen. Op geen enkele manier. Zolang dat gebeurt hoort 't absoluut niet in de basis Linux setup thuis.

[Confusion]

Elke nieuwe functionaliteit bestaat uit 'een berg patches'.

[dasiro]

Wanneer ext3 met deze patch gebruikt wordt, zullen oude bestanden op de conventionele wijze behandeld worden. Nieuwe bestanden worden op de nieuwe manier opgeslagen

zijn de nieuwe bestanden dan nog wel compatibel met het oude ext3 ?

[KoHa]

Verder betekent het invoeren van het bijgewerkte ext3 dat nieuw gemaakte bestanden niet gelezen kunnen worden door de oude ext3-driver, omdat die niet kan omgaan met de nieuwe bestandsstructuur.

Lezen is een schone zaak...