ReiserFS 4 bestandsysteem uitgebracht

Enkele dagen geleden is een nieuwe versie uitgebracht van het Linux-bestandssysteem ReiserFS. De nieuwe versie 4 van ReiserFS beschikt over enkele belangrijke verbeteringen ten opzichte van de oude versie. Zo is er een plug-in gebaseerde architectuur waardoor het eenvoudig is uitbreidingen te schrijven voor het bestandssysteem. Daarnaast is het bestandssysteem uiteraard voorzien van een journal, waardoor eventuele stroomstoringen niet leiden tot een corrupt bestandssysteem.

Ook de performance van ReiserFS 4 is goed, volgens de ontwikkelaars. Met name wanneer er veel kleine bestanden aanwezig zijn op de schijf is de snelheid verbeterd ten opzichte van de vorige versies. De nieuwste versie van ReiserFS is ontwikkeld met veiligheid en betrouwbaarheid als speerpunt. De broncode is dan ook voorzien van assertions voor elke functie, die de preconditie voor de betreffende functie controleren.

Daarnaast zijn vrijwel alle bewerkingen van het filesysteem atomair, wat wil zeggen dat ze volledig plaatsvinden of helemaal niet, maar het is onmogelijk dat een bewerking maar deels wordt doorgevoerd. ReiserFS wordt onder andere standaard gebruikt door de Linux-distributies van Suse en Lindows, beide ook sponsoren van de ontwikkeling van ReiserFS 4. Of en wanneer deze distributies ook overstappen naar ReiserFS 4 is niet bekend. Het is wel mogelijk om met de hand het ReiserFS 4 bestandssysteem te installeren onder Linux. De benodigde kernel-patch kan hier worden gedownload. Overigens is ReiserFS 4 alleen beschikbaar voor de Linux-kernel 2.6.

Reacties (62)

[MoonWatcher]

Een andere (maar stukken minder bekend) feature van reiser4 is de "file as directory" feature. deze feature betekend dat een bestand op de harde schijf zowel een file als een directory is. (afhankelijk van hoe hij benaderd word). dit is vooral handig voor de opslag van metadata.

voorbeeld:

mplayer blah.mp3 [enter]
(mplayer begint met spelen van mp3)

cd blah.mp3 [enter]
ls [enter]
(ls geeft nu allemaal files weer zoals Title, Artist, Album, enz)
deze bestanden bevatten dan elk de metadata van de mp3 (in plaats van bijvoorbeeld taglibs voor metadata), en kunnen ook allemaal aparte rechten hebben. en doordat reiser4 kleine bestanden zo efficient inpakt is dit ook nog niet eens zoveel ruimte vretend.

mp3s is misschien niet de nuttigste om uit te splitsen maar op het moment dat het over beveiligings tools gaat kan dit toch zeker lonend zijn. de namesys website noemt als voorbeeld het opsplitsen van /etc/passwd

[Anoniem: 113286]

Wat betreft beveiliging. Als het gaat om encryptie van data op de harde schijf dan is elk bestandssysteem voorzien van een journal een security risk.

In dat geval zou ik binnen linux nog altijd voor EXT2 kiezen

[LinuxMan]

Als het gaat om encryptie van data op de harde schijf dan is elk bestandssysteem voorzien van een journal een security risk.

wat een bullshit, er zijn twee manieren om encryptie te doen: 1) boven het level van het filesystem, dus de data die gaat al encrypted naar het fielsystem, en zal dus ook in de journal met encyptie staan. 2) het filesystem op een encrypted block device zetten, en dan zet je de journal ook op het encrypted device, en dan is dus ook die encrypted.

[freggy]

ReiserFS4 lijkt me helemaal nog niet klaar om in productie-omegevingen gebruikt te worden. ReiserFS4 is nog nog niet op voldoende grote schaal getest (maar dat zal nu zeker wel snel gebeuren, nu het "stabiel" is verklaard).

Een van de problemen die er bijvoorbeeld zijn, is een probleem met Apache, doordat ReiserFS4 een bepaalde systeemfunctie anders laat reageren dan alle andere bestandssystemen: http://marc.theaimsgroup.com/?l=reiserfs&m=109337306111262&w=2

[Bloody NO!]

Op de site van Gentoo Linux vond ik dit:
\\\\\\\"ReiserFS is a B*-tree based filesystem that has very good overall performance and greatly outperforms both ext2 and ext3 when dealing with small files (files less than 4k), often by a factor of 10x-15x. ReiserFS also scales extremely well and has metadata journaling. As of kernel 2.4.18+, ReiserFS is solid and usable as both general-purpose filesystem and for extreme cases such as the creation of large filesystems, the use of many small files, very large files and directories containing tens of thousands of files.\\\\\\\"
@Xarenion: SuSE werkt al een tijdje met ReiserFS... vanaf versie 8.2 dacht ik

[Anoniem: 34356]

Op de Gentoo website wordt gesproken over ReiserFS.
Dat is de vorige versie van ReiserFS, namelijk v3. De nieuwe en totaal herschreven versie is v4 ofwel Reiser4 of ReiserFS4.

[n4m3l355]

ik vraag me af hoe het dan performed wanneer je gebruik maakt van 128kb blocks of nog groter wat meestal toch wel te zien is op grotere partities. of het dan alsnog zo effecient is.
maar ik denk dat het zowieso nog wel even aanzien nu het gebruikt wordt door meer mensen op bugs en dan dat het dan tijd is voor eigen gebruik. zeker wanneer bedrijven erop over gaan kun je er toch wel een beetje zekerder van zijn of het goed performed

[packman]

ReiserFS4 is daar de vreemde eend in de bijt - het gebruikt helemaal geen blocks meer...

[buum]

Nu wachten op een partij die dit gaat testen in een Corporate environment. Wat zal dit bijvoorbeeld voor effect hebben op database-performance, waar bijna geen kleine bestanden worden gebruikt.

Misschien dat het onderzoeksbureau dat MS en Linux heeft vergeleken in de UK, nog op zoek is naar een opdracht .

[Anoniem: 53444]

Nu wachten op een partij die dit gaat testen in een Corporate environment. Wat zal dit bijvoorbeeld voor effect hebben op database-performance, waar bijna geen kleine bestanden worden gebruikt.

Daar is reiser sterk af te raden
gezien een database al gauw bestanden heeft van een paar gig.
Er is overigens meer dan ext2, ext3 en reiser. Jammer dat de meeste dat nog niet helemaal doorhebben

voor Databases is overigens XFS de favoriet

[Vorlon]

Over xfs heb ik ook lang zitten dubben, maar als je dat wil hebben bouw je bijna de kernel in xfs dan andersom. Tenminste dat was altijd zo, weet niet zeker of dat bij de huidige versie ook nog zo is.

naja, het komt er nog wel een keer van als ik zin heb om m'n server weer eens te herinstalleren. (zoals eigenlijk een maand geleden had gemoeten omdat m'n win2003 cpp licentie is afgelopen, als ik nu moet herstarten doet ie het niet meer )

[Bas!]

Functionaliteit kost wat. Als je die modulegrootte echt zo'n probleem vindt kan je de trade-off naar jfs maken.
Maar goed wil je het natuurlijk echt goed doen dan ga je voor je db niet met bestandssystemen klooien, dat zit immers al in je db als ie bestanden maakt van zoveel gieg

[Anoniem: 93552]

Ik zie hier een heleboel vergelijkingen met ext2 en ext3, is hier niemand die xfs heeft uitgeprobeert?

Het is misschien niet zo snel als ReiserFS, maar heeft wel ondersteuning voor POSIX ACL\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'s (net als NTFS maar dan alleen rwx ipv een heleboel extra ingen als List etc) en Metadata.

Dit filesystem draait bij mij als een raket, is stabliel en zeker beter als ext2/3 en Reiserfs (qua functionaliteit).

Het gaat wel iedere keer over snelheid, maar ik denk dat dat nu niet meer zo heel erg van toepassing is (wie maakt er nu no bestanden < 4 kb?). Volgens mij is functionaliteit hierbij nu veel belangrijker. Al helemaal als je kijkt naar wat WinFS gaat doen.

[Anoniem: 91916]

(wie maakt er nu no bestanden < 4 kb?)

Ik heb hier een projectje met meer dan 450 .java files die bij het compileren meer dan 450 .class files opleveren.
Bijna allemaal < 4k.

Kerneltje compilen anyone? -> .c/.h/.o files.

Ah, ik heb hier nog een website draaien -> .html .css .php

Oh ja, ik heb hier nog een browser die graag .html files cached...

Even de /etc directory doorspitten. Tsjonge wat zijn die configfiles klein zeg.

[Anoniem: 93552]

waar ik het over heb zijn de wat meer voorkomende dingen en kernelje compilen, etc directory enz bedoel ik daar niet mee, en ik zit er echt niet mee als dat wat langer duurt.... als het goed is zit je toch niet ieder uur in de configs te rommelen (beter nog te zoeken).

Wat dacht je van filesharen (samba?) ooit een heleboel word documenten gezien die kleiner zijn als 4kb?

XFS valt trouwens prima tussen ext3/2 en reiserfs in en mijn etc dir verscheijnt nog steeds binnen een halve sec. Dit is dus ook absoluut niet wat ik bedoel.

[AQuaTiX]

Dan heb je het over binary documenten zoals word documenten, zipfiles etc.

Mensen in de *nix wereld [zoals ik] hebben nogal om plain text files te gebruiken. Deze zijn prima te processen met shell scripts [think grep etc] en waarom zou je daarvoor een zware wordprocessor voor gebruiken? En ik kan zo nog wel wat meer kleine files vinden op m'n systeem.

Ook onder windows kom ik sloten aan kleine bestanden tegen [vooral met TotalCommander is het dan leuk om te kijken hoeveel drivespace je waste door de slack].

En over "wat meer voorkomende dingen": dat ligt er helemaal aan wat je doet met je pc. Als je alleen maar in word tikt, mp3's en films download heb je natuurlijk weinig last van de slack aan het einde van elke file.

"Volgens mij is functionaliteit hierbij nu veel belangrijker. Al helemaal als je kijkt naar wat WinFS gaat doen.": zie een paar posten hierboven; het "file as directory" is een leuke gimmick waarmee je via scripts of wat dan ook krachtigere [en snellere] trucks kan uithalen dan WinFS met z'n mega database.

Just my 0.02 EUR

[terabyte]

(wie maakt er nu no bestanden < 4 kb?)

Je zult verbaast staan over de hoeveelheid kleine bestanden op je systeem....

[Anoniem: 87095]

Ik draai al 3 dagen reiser4 op alle fs behalve /boot met 2.6.8.1-mm4 en 't lijkt (heel subjective) sneller of ten minste veel minder HD access.

xming

[Ploink]

Reiserfs is niet gebaseerd op inodes zoals ext2/3. Het aantal inodes is vastgesteld bij het formatteren van de partitie en voor elke file heb je er 1 nodig.
Ooit hadden we een webcache (squid) lopen op ex2 en op een dag waren de inodes op door de vele kleine files. Het systeem kon geen enkele nieuwe file meer maken terwijl er nog genoeg megabytes vrij waren op de schijf. We zijn toen overgegaan op reiserfs en zelfs met een miljoen files op slechts 5 gigabyte geen problemen meer :-) Sindsdien draai ik thuis ook op reiser.

[tweakduke]

Ik ben nog niet zo super bekend met alle linux bestandssystemen.

Wat ik me nu zo afvraag, hoe verhoud deze reiserFS versie zich tegenover de ext2 en ext3 (en andere bestandssystemen)

[breinonline]

Alleen met een benchmark ben je er niet. De bestandssystemen zijn namelijk niet met dezelfde uitgangspunten ontworpen. Ze hebben dan ook allemaal hun eigen voor- en nadelen. Hier wordt het een en ander uitgelegd.

[Anoniem: 109077]

Het is vast beter dan FAT(32), maar hoe zit dat tov NTFS 5.1?

[Anoniem: 117693]

ntfs en reiserfs zijn niet echt te vergelijken. ntfs heeft nog last van dingen als "fragmentatie". Technologie uit de jaren '70 dus. Te zielig voor woorden gewoon.

Wat ik trouwens niet in het nieuwsbericht lees: ntfs en reiser3 zijn, in tegenstelling tot Reiser4, filesystemen met data journalling. Dwz alle data wordt 2 x geschreven: 1 x gewoon en 1 x in een journal (logboek van wat je aan 't doen bent op je filesysteem). Als de boel vastloopt kijkt het OS bij 't opstarten in 't journal wat er gebeurde vlak voor 't vastlopen, en zo fixt-ie de boel. Linux zegt bij mij (Reiserfs 3.6): "replaying journal", en binnen een paar seconden start-ie door. NTFS doet ongeveer hetzelfde.

Da's ook 't verschil tussen ext2 en ext3. Ext3 is ext2 met een journalling-toevoeging. Betrouwbaarder maar trager. Helaas wil Linux soms ook nog een volledige filesystem check doen, en dat vind ik toch wel irritant. Bij Reiser3 en Reiser4 hoeft dat niet.

Reiser4 echter, schrijft de data niet 2 x, maar doet 't op de een of andere manier slimmer. (kijk op namesys.com voor meer info). Hij heeft wel iets van een journal, maar hij hoeft lang niet alles 2x naar schijf te schrijven, wat natuurlijk stukken sneller is. Toch is hij "atomic", wat onder andere betekent dat je filesysteem niet in een niet-consistente staat kan komen als de boel vastloopt.

FreeBSD's UFS-2 heeft dat trouwens ook: niet volledig journallen en toch atomic (en dat werkt ook erg oke kan ik uit ervaring zeggen).

[Soultaker]

FreeBSD's UFS-2 heeft dat trouwens ook: niet volledig journallen en toch atomic (en dat werkt ook erg oke kan ik uit ervaring zeggen).

De features die jij noemt (snapshotting en eventueel background checking) bestonden ook al voor UFS1. UFS2 heeft vooral meer support voor bestandsattributen, hoogt een aantal limieten op, en optimaliseert een aantal allocatiealgoritmes. Het consistent houden van het filesystem met snapshotting kan echter met zowel UFS1 als UFS2.

[Soultaker]

Je zal inderdaad altijd last krijgen van fragmentatie als de schijf vol raakt. Zoals je zelf al aangeeft zijn er scenario's te bedenken waarin dat onvermijdelijk is. Het is echter wel mogelijk om door handig te plannen fragmentatie tot een minimum te beperken. Dat zit 'm vaak in het van te voren alloceren van ruimte voor bestanden of datastructuren die nog moeten groeien (zoals logfiles, maar ook interne datastructuren) en het handig verspreiden van bestanden over de harde schijf.

FAT16 onder DOS was een vrij simpel systeem en de structuur van FAT alsook de algoritmes die DOS gebruikt voor de allocatie van bestandsruimte veroorzaken relatief veel fragmentatie.

Moderne bestandssystemen zoals UFS, EXT2 en NTFS zullen dus bij normaal gebruik echter veel minder gedefragmenteerd raken. Bedenk dat het helemaal niet erg is als er een beetje fragmentatie optreedt; het wordt pas merkbaar als veelgebruike bestanden en datastructuren in veel fragmenten opgedeeld zijn. Die bestandsystemen zijn vaak zo ontworpen dat de gegevens tijdens het gebruik worden geordend, waardoor de fragmentatie niet steeds toeneemt zoals bij FAT, maar op een bepaald peil blijft.

Ik heb het nooit in detail uitgezocht, maar ik denk dat NTFS onder Windows 2000 of XP redelijk vrij blijft van storende fragmentatie. Ik ben dan ook wel nieuwsgierig waar TheFonz zijn gegevens vandaan heeft. Bij normaal gebruik denk ik dat je een NTFS partitie ook niet hoeft te defragmenteren (al kan het natuurlijk wel), net zoals dat voor UFS of EXT2 niet nodig is.

Overigens is niet alleen de indeling in het bestandssysteem van belang. Moderne besturingssystemen herschikken ook lees- en schrijfoperaties op een manier die aangepast is aan de eigenschappen van een harde schijf. Daardoor kan een Linux kernel soms efficienter bestanden uit FAT16 partitie uitlezen dan bijvoorbeeld DOS dat kon, terwijl de gegevens op de partitie hetzelfde zijn.

[_Thanatos_]

Dat je op linux niet hoeft te defragmenteren, is een misopvatting. Ik weet niet wat er precies gebeurt, maar het is absoluut noodzakelijk. Fragmentatie is gewoon onvermijdelijk. Je ziet het dan ook in veel meer datastructuren dan alleen FSen terugkomen. Denk bijvoorbeeld aan een database of de heap.

Fragmentatie is trouwens heel eenvoudig op te wekken op *ieder* willekeurig bestandssysteem. Maak een paar bestanden en ga ze vervolgens groter maken. Het systeem zou knettergek zijn om bij iedere uitvergroting van een bestand het hele ding te verplaatsen naar een plek waar genoeg aaneengesloten vrije ruimte is, hence, het fragmenteert. En maar goed ook.

Een andere misopvatting is dat directories niet fragmenteren. Laat ik iedereen uit de droom helpen: dat doen ze wel. Een directory is een soort lijst met bestanden, dus als je meer bestanden in een directory kopiëert, kan die directory gefragmenteert raken.

Dit alles natuurlijk weer afhankelijk van de clustergrootte. Met grotere clusters is er meer ruimte voor kleinere veranderingen van grootte in bestanden en directories. Handig voor partities met logfiles dus, om grote clusters te definiëren (NTFS kan om deze reden zelfs tot 128KB clusters)

Kortom, een niet-fragmenterend bestandssysteem kan *niet*. Geen twijfel over mogelijk.

[LinuxMan]

Kortom, een niet-fragmenterend bestandssysteem kan *niet*. Geen twijfel over mogelijk.

jouw hele verhaal druipt van de fat16 kennis, maar mist nog wat modernere saus. Ga eens op namesys lezen wat er allemaal voor truucjes zijn om fragmentatie tegen te gaan. een directory is bijvoorbeeld geen lijst namen meer, maar een moderne variant van een balanced tree. kleine files kunnen zelfs met data en al in deze tree gezet worden, zodat er minder fragmentatie bij grotere files is. etc. etc. Eerst lezen, dan posten.

[Battle Bunny]

Kun je dit toelichten? Hoe kun je nou geen last hebben van fragmentatie? Als je een 64kb bestand weggooit, heb je maar zoveel ruimte over. Een 128Kb past dan half daar, en half ergens anders: hence, fragmentatie. Dit is toch normaal voor een FS (* 786562 Battle

[LinuxMan]

Hoe kun je nou geen last hebben van fragmentatie? Als je een 64kb bestand weggooit, heb je maar zoveel ruimte over. Een 128Kb past dan half daar, en half ergens anders: hence, fragmentatie.

maar een 128 kb bestand moet je daar dus ook niet neerzetten als je een slim bestandsysteem bent ;-)

overigens is dit niet nieuw van reiserfs, zelfs ext2 heeft al vrijwel geen last van fragmentatie zolang de gebruikte disk ruimte onder de 90% blijft.

(edit: tikfout)

[reinouts]

Dat je op linux niet hoeft te defragmenteren, is een misopvatting. Ik weet niet wat er precies gebeurt, maar het is absoluut noodzakelijk.

Dat het optreden van fragmentatie onvermijdelijk is, daarin heb je gelijk. De vraag is alleen of het in zo'n grote mate gebeurt dat een defragmentatie-procedure noodzakelijk is. Bij ext2/3 en reiserfs is dat niet zo, getuige het feit dat niemand het nodig heeft gevonden om een defragger ervoor te schrijven. De allocatie-algoritmes zijn slim genoeg om fragmentatie binnen de perken te houden.

[nAFutro]

NTFS 5.1 bestaat niet...
FAT is inderdaad erg verouderd, reiser lijkt op zich redelijk op ntfs dus daar zit het niet echt veel vanaf.

[musiman]

ntfs 5.1 bestaat wel... Windows XP en Server 2003 gebruiken dit. Intern (met een speciaal tooltje) lees je nog wel dat het versie 3.1 zou zijn, maar extern (lees: Microsoft zegt het) is het 5.1.

En inderdaad lijkt ReiserFS het meest op NTFS vanwege de journaling functionaliteit die in beide aanwezig is. Maar ook Ext3 heeft journaling als optie. Deze is echter trager dan ReiserFS 4.

[Q-collective]

En inderdaad lijkt ReiserFS het meest op NTFS vanwege de journaling functionaliteit die in beide aanwezig is.

Ik zou eerder zeggen dat NTFS nu op ReiserFS leek, NTFS is immers zo ouderwets geworden (zeker tov Reiser 4 )

[Proxy]

Klopt, Windows XP en Windows Server 2003 gebruiken NTFS5.1, Windows 2000 gebruikt NTFS5.0 (voorheen NTFS5).

[_Thanatos_]

Windows 2000, XP en 2003 gebruiken NTFS 3.0, Windows NT4 gebruikt NTFS 2.0 en NT 3.x gebruikt NTFS 1.0. Dan is dat misverstand ook weer de wereld uit.

[LinuxMan]

En inderdaad lijkt ReiserFS het meest op NTFS vanwege de journaling functionaliteit die in beide aanwezig is.

om dat nou 'lijkt op' te noemen??? dan lijken ntfs/xfs/jfs/etx3 dus allemaal op elkaar?? als er een filesystem is waar ntfs nog in de verste verte niet op lijkt is het ntfs wel.

als je benchmark resultaten van een suite als 'mongo' ziet op ntfs versus reiserfs (en dan hebben we het nog niet over reiserfs4 die nog weer sneller is) dan zie is er weinig reden om ze te vergelijken denk ik.

(edit: tikfoutjes)

[Q-collective]

Benchmarks

[BartOtten]

Dit klinkt er goed. Op dit moment heb ik nog wel eens storingen in mijn PC (vrij oud) en als er op dat moment iets word weggeschreven dan ben ik vaak de pineut. Ik hoop dat dit het allemaal een beetje oplost (nieuwere PC is ook niet slecht).

Ik hoop dat iig SuSe het snel introduceerd. Dan kan ik zelf meemaken of het helpt.

Begrijp ik nou goed dat het aankoppelen van nieuwe HD's makkelijker is geworden?

[Anoniem: 120247]

Begrijp ik nou goed dat het aankoppelen van nieuwe HD's makkelijker is geworden?

Hoezo was dat ooit een probleem dan? Gewoon formatteren en gôan môar, zo is 't hier iig altijd gegaan, met welk filesystem dan ook

[Gover]

Dus het voornamelijk op veiligheid gestoeld, en in mindere mate op performance, ideaal dus i.c.m. een RAID 5 in je thuisservertje

[Anoniem: 38402]

Dus het voornamelijk op veiligheid gestoeld, en in mindere mate op performance, ideaal dus i.c.m. een RAID 5 in je thuisservertje

Ehm, je hebt niet veel aan RAID als je filesysteem door een bug corrupt wordt.

Ik zou even wachten met het gebruiken van willekeurig elk nieuw filesysteem als je voor de veiligheid van data gaat.