NTT ontwikkelt nieuw Linux-bestandssysteem

Onderzoekers van de Cyber Space Laboratories van het Japanse NTT hebben een nieuw open-sourcebestandssysteem voor Linux gepresenteerd. Versie 1.0 van NILFS, een afkorting voor 'New Implementation of a Log-structured FileSystem', moet betrouwbaarder en sneller zijn dan conventionele Linux-bestandssystemen als ext3, terwijl de beveiliging van de data aanzienlijk beter zou zijn dan die van UFS, het systeem dat Sun in Solaris heeft geïmplementeerd.

Het belangrijkste kenmerk van het nieuwe systeem zou de 'log-structured'-benadering zijn. Bestanden worden met deze aanpak niet overschreven; nieuwe gegevens worden aan het bestandssysteem toegevoegd zoals dat bij logbestanden gebeurt. Om de integriteit van bestanden te verzekeren kan permanent een 'snapshot' van het systeem worden bijgehouden. Suns UFS kan dat ook, maar dat systeem vereist dat het disksysteem wordt gedeactiveerd voordat een snapshot gemaakt kan worden. Een voordeel boven conventionele 'journaling'-systemen is dat NILFS-snapshots kunnen worden uitgelezen terwijl het bestandssysteem zelf in gebruik is, wat behulpzaam moet zijn bij het herstellen van data die bij een crash onverhoopt toch verloren is gegaan.

Op het eerste gezicht lijken kenmerken als een korte hersteltijd en een hoge mate van integriteit na een crash niet veel toe te voegen aan bijvoorbeeld ReiserFS, maar het nieuwe systeem zou bovendien bijzonder snel en efficiënt kunnen schrijven - wat geen verbazing wekt vanwege de lineaire opslagmethode. Dankzij de gebruikte binaire-boomstructuur moeten ook zoekoperaties flink aan snelheid winnen. De zogenaamde 'loadable kernel module' is per direct te downloaden, maar gegeven de lengte van de 'todo'-lijst lijkt dat vooralsnog alleen voor zéér experimentele setups de moeite waard.

Reacties (25)

[Blaurens]

..maar gegeven de lengte van de 'todo'-lijst lijkt dat vooralsnog alleen voor zéér experimentele setups de moeite waard.

Niet alleen de lengte, ook de inhoud geeft aan dat eea nogal experimenteel is. Een bloemlezing van de todo:

- Better error handling.
- Basic administration tools such as fsck.
- Redundant mechanism for critically important blocks (the super block and the segusage blocks).

om maar een paar dingen te noemen. Klinkt veelbelovend, maar het heeft als jong filesystem natuurlijk nog wel een lange weg te gaan.

[-=bas=-]

Bestanden worden met deze aanpak niet overschreven; nieuwe gegevens worden aan het bestandssysteem toegevoegd

Een Novell fileserver had dat 10 jaar geleden ook al.

Waarom zo'n systeem uberhaupt niet in Linux zat is me altijd een raadsel gebleven.

[zalazar]

Ja, en de huidige Windows 2003 servers ook m.b.v. Shadow copy services.

Edit:
Verder lijkt het me wel handig om te weten hoe de fragmentatie is. ReiserFS en ext3 hoeven nagenoeg niet gedefragmenteerd te worden.

[Toreador]

Zalazar, windows vss zit in memory, laatste keer dat ik onze windows beheerders hoorde klagen over het niet functioneren van VSS op hun clusters.....

[Verwijderd]

Schrijfsnelheid verbeterd/beter dan anderen.

Goed voor webhosting.

Ik vind dat bij de eeste servers een groot bestand met php achrijven te lang duren (ext3 (?), CentOS).

[Defspace]

En ligt dat aan de server, configuratie, php of ext3 Ik denk... niet het laatste

[Verwijderd]

Zo bedoel ik het niet. Je kan natuurlijk niet zeggen: "Wat zal ik nemen: Ext3 of php". Net als: "Wat is beter:hardware of software".

Als je de schrijftijden meet (via php) om een bestand van meerdere kilobytes weg te schrijven duurt dat lang. Sql query's nog meer dus het is nog geen vertragende factor.

[YoMarK]

Voor webhosting is de snelheid van een filesystem in de meeste gevallen niet al te belangrijk.
Anders gezegt: in de meeste gevallen is het verschil dus tussen verschillende filesystems niet erg te merken, zeker niet in het geval van dynamische content(php).
Dus ik snap je stelling "Goed voor webhosting" niet zo, want er zijn legio toepassingen denkbaar die veel meer kunnen profiteren van een sneller filesystem.

[Cybje]

Mark Lavrijsen: dat is sterk afhankelijk van wat je ermee doet. Als je een stuk of 100-200 PHP sites erop hebt draaien die allemaal uit SQL databases hun gegevens plukken (zoals forums) is een filesystem dat bijv. geoptimaliseerd is voor lage zoektijden heel erg interessant. Ik zie vaak genoeg op een server dat de harddisk de vertragende factor is (ja of het geheugen, omdat je met meer geheugen meer in de cache kunt smijten).

Natuurlijk zijn er veel toepassingen te verzinnen waarvoor een snel filesystem interessant is, maar juist voor webhosting met random reads/writes ipv sequental reads/writes is het wel interessant denk ik.

[Vectrox]

Ik zie het nut niet echt voor webhosting.. Je zult die snelheid vrijwel niet merken voor webhosting.

[pietje63]

Juist niet.. Als ik dit zo lees dat krijg je een vrij ge fragementeerd bestandsysteem en bij lezen dus langsamer... En wat doet een webserver vooral, juist bestanden lezen.

[Verwijderd]

Alleen interessant voor databases zoals jij het stelt en dan alleen nog als de server zwaar belast word.

[Verwijderd]

Bestanden worden met deze aanpak niet overschreven; nieuwe gegevens worden aan het bestandssysteem toegevoegd

Dit klinkt ook een beetje richting een CVS achtig filesystem, waarvan op al je bestanden automatisch versioning wordt toegepast.

[leuk_he]

Oude bestanden worden uiteraard vanzelf overschreven. Het is me niet duidelijk of alle schrijfacties gelogd worden of alleen de directory struktuur. Ext3 en rfs kunnen ook alles loggen, maar standaard schijft hij alleen de diskstukturen naar een log.

[WoBBeL]

NILFS, MILFS...en die M en N toets zitten al zo dicht bij elkaar

[Mizitras]

Ik als toegewijde moeder van vier bloedmooie dochters van kinders die af en toe ook nog wat surft begrijp dit niet. Wat bedoel je; waarom vindt men jou grappig?

[Olaf van der Spek]

terwijl de beveiliging van de data aanzienlijk beter zou zijn dan die van UFS

Wat voor beveiligingsfeatures zijn er beschikbaar dan?

[blade181]

Ik vraag me eerder af hoe dit nieuwe bestandssysteem presteert ten opzichte van het reiser4 systeem. Dat bestandssysteem is al een tijdje uit, maar nog steeds in testfase. Hoewel dat nog even kan duren moet het naar mijn inziens binnenkort wel opgenomen worden in het de standaard vanilla kernel sources.

Verder lijkt het me nog niet heel interessant, misschien wel als een opslagsysteem maar niet als root filesystem. Grub zal er vast nog niet mee om kunnen gaan wat er dus voor zorgt dat je er niet van kunt opstarten. Het bestandssysteem zou zich eerst moeten bewijzen voordat het echt standaard opgenomen zal worden.

[Sir Isaac]

Tja, Japan is duidelijk een eiland. Volgens mij heeft VMS dit al meer dan 12 jaar. 6 jaar geleden gebruikte ik bij mijn afstuderen een VAX/VMS computer die toen al antiek was, en die had deze functies al.

[beerse]

Met al die journalled filesystemen en zo mis ik de laatste tijd het versioned-filesysteem dat VAX/VMS altijd al bood. Daarmee kan je altijd oude versies van de files terughalen. Wat ik me herinner is dat standaard de laatste 3 versies van een file konden worden teruggehaald, gewoon van file. Met de journals en logs moet dat toch betrekkelijk eenvoudig te regelen zijn?

[lvh]

Het grote probleem wat nu nog overblijft is ondersteuning. Dat het bestaat is allemaal goed en wel, maar het zit oa nog niet in de vanilla kernel, waardoor je weer zelf zal moeten patchen en builden, wat in een productieomgeving niet vanzelfsprekend is.
Bovendien moet je de userspace tools nog werkend zien te krijgen. Hoe minder pakketjes een sysadmin manueel moet onderhouden, hoe beter. Als de userspace tools niet door de distributie wordt gegeven, is dat wel de enige optie...

[yootje]

RTFA, het is nog in hoge betafase:

De zogenaamde 'loadable kernel module' is per direct te downloaden, maar gegeven de lengte van de 'todo'-lijst lijkt dat vooralsnog alleen voor zéér experimentele setups de moeite waard.

Dit is (nog) niet voor de normale gebruiker bedoeld, laat ze het eerst maar eens goed maken.

[borft]

dude, ik denk dat elke zichzelf respecterende sysadmin zelf zijn kernels patched en compileert. Als je standaard redhat install kernels gaat draaien kan je net zo goed je rootwachtwoord op je website zetten.

[4VAlien]

Jij controleert de source van alle patches die je toepast? Jij hebt hard bewijs dat de stabiliteit en/of veiligheid van je systeem erop vooruitgaan? Hoe uitvoerig is je eigen in elkaar geklutste setup getest en bugvrij na het combineren van verschillende patches? En hoe vaak was een vanilla kernel de oorzaak van een gehackt systeem? Een paar vragen die me zo te binnen schieten...