Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 91 reacties
Submitter: PrisonerOfPain

Microsoft heeft details vrijgegeven van het filesystem dat voor Windows 8 werd ontwikkeld. ReFS staat voor Resilient File System en het nieuwe bestandssysteem zal voorlopig alleen voor de serverversie van Windows 8 worden gebruikt.

Het ReFS dankt zijn naam aan de mate waarin het bestand is tegen hard- en softwarefouten; bij stroomuitval bijvoorbeeld zou data op een server met ReFS niet verloren moeten gaan. Ondanks de nieuwe naam is ReFS omwille van de compatibiliteit nog steeds deels gebaseerd op het bekende ntfs, dat in de huidige Windows-producten gebruikt wordt. ReFS zou ntfs niet gaan vervangen in consumentenversies van Windows; alleen in Windows 8 Server zou het nieuwe bestandssysteem worden gebruikt.

In een blogpost doet een van de ontwikkelaars van ReFS uit de doeken wat de belangrijkste features en ontwerpcriteria van het bestandssysteem zijn. Naast de backwards compatibility met ntfs moet het bestandssysteem geschikt zijn voor zeer grote opslagvolumes en moet corrupt geraakte data automatisch gerepareerd worden, waarbij het bestandssysteem continu beschikbaar blijft. Ook zouden volumes over verschillende schijven en systemen verdeeld kunnen worden om de beschikbaarheid te optimaliseren en de belasting te verdelen.

De data wordt weggeschreven door een nieuw ontwikkelde storage engine in zogeheten B+ trees. Niet alleen de data zelf, maar ook metadata als directory-structuren wordt in tabellen in deze B+ trees weggeschreven. Wijzigingen in bestanden worden altijd op een andere locatie dan het origineel weggeschreven, wat datacorruptie in geval van een schrijffout moet voorkomen.

De vernieuwde structuur van het bestandssysteem ondersteunt bestanden die maximaal tien triljoen bytes groot kunnen zijn, terwijl een volume zelfs een tredeciljoen, of 10^78 bytes groot mag zijn. Een volume mag tien triljoen directories bevatten, die ieder weer evenveel bestanden kunnen bevatten. Een storage pool is maximaal 4PB groot, maar er is geen limiet aan het aantal storage pools. Windows Server 8 kan overigens niet van een ReFS-schijf starten; het is puur als opslagmedium bedoeld.

Moderatie-faq Wijzig weergave

Reacties (91)

Jammer dat het vorige artikel op de Building 8 blog door de t.net redactie genegeerd is: http://blogs.msdn.com/b/b...iency-and-efficiency.aspx

Waarin wordt beschreven dat op Windows 8 client Storage Spaces en Pools beschikbaar komen waarmee je een virtuele volume kan maken van 50TB met bijv een paar TB schijven. Pas als die limiet bereikt wordt hoef je er nieuwe schijven bij te zetten. Plus er is ook verhoogde betrouwbaarheid doordat data 2 of 3x opgeslagen kan worden (a la RAID). Lijkt me voor consumer NAS gebruik zeer handig.
Onduidelijk voor mij is of ReFS nu checksums gebruikt om corruptie te detecteren, of dat het simpelweg van een mirror leest indien de primary onleesbaar is. Dat laatste is niets bijzonders, dat eerste wel.

Mijns inziens is elk filesystem wat geen bescherming tegen corruptie heeft geen volwaardig filesystem maar meer iets als 'FAT32'; primitief, niet geavanceerd. Met name de metadata heeft bescherming nodig, ook op een volume zonder redundancy. Voor zover ik weet zijn alleen ZFS en Btrfs filesystems die dit implementeren, waarbij Btrfs onder alpha/beta kwaliteit valt en ZFS overblijft als enig volwaardig en bruikbaar filesystem op dit moment.

Ik denk even terug aan WHS waarbij de populaire feature Drive Extender (DE) geslachtoffert werd; de nieuwe DE 2.0 had bit-rot protectie maar was niet langer compatible met DE 1.0. Uiteindelijk is DE 2.0 net als het vroegere WinFS gecancelled, en bleef Windows zitten met een redelijk verouderd bestandssysteem (FAT + NTFS).
Onduidelijk voor mij is of ReFS nu checksums gebruikt om corruptie te detecteren, of dat het simpelweg van een mirror leest indien de primary onleesbaar is. Dat laatste is niets bijzonders, dat eerste wel.
Dat laatste is onmogelijk tenzij je meer dan een mirror hebt. Je weet dan niet of schijf A of B correct is, zonder ook de semantiek van de file in kwestie te kennen.

ZFS doet dat overigens zo bij mirrors of met parity info bij hogere RAID levels.
Volgens een link waarnaar in het Wiki-artikel verwezen wordt (http://blogs.msdn.com/b/b...tem-for-windows-refs.aspx), slaat ReFS bij elke page een checksum op. Wordt de page ingelezen, en blijkt de data niet overeen te komen met de checksum, dan is er dus sprake van corruptie (omdat bijvoorbeeld de disk-controller de data niet goed heeft weggeschreven, of "bit-rot" op de disk). Indien beschikbaar zal de data dan van een logische mirror worden ingelezen, is dat niet mogelijk dan krijg je een read-error.
Puur mirroring is sowieso niet interessant. De computer kan simpelweg niet bepalen wat de correcte is van de 2 bij silent corruption (als ie bad blocks errors krijgt kan ie wel conclusies trekken natuurlijk). Het kan goed voorkomen dat het resultaat is dat de foute data daarom de goede overschrijft.

Moraal van het verhaal: Checksumming rules, mirroring sucks.
bij stroomuitval bijvoorbeeld zou data op een server met ReFS niet verloren moeten gaan.
Ik concludeer hieruit dat write caching verleden tijd is?
Op veel server toepassing is dat al lang hoor. Het ligt er maar net of je snelheid of potentieel verlies hoger waardeert. Veel RAID controlles schakelen de disk write caching al lang uit, hier voor in de plaats komt vaak battery backed write cache op de controller zelf.

Daarnaast kun je sync of async programmeren (low-level). En write-caching is evil voor sync, je gebruikt dat normaliter niet voor niks :). Het is niet bepaald alsof de snelheid er beter van wordt nl.
Ja en Nee, en hangt ook van je controller af. Als je writeaching aan zet en je disk heeft geen garantie mechanisme is die data inderdaad kwijt maar dat is nu ook al zo. (Met garantie als flash buffer heb je dit porbleem niet)
Probleem nu is alleen dat als de helft van je schrijf actie al naar disk is gecommit en de andere nog niet en de stroom uitvalt je bestand corrupt it en je dus ook het oude bestand niet hebt. Met de nieuwe optie wordt de pointer naar het segment in de TOC pas aangepast als de write complete is. Kost even iets meer ruimte (8 of 16 k want schrijf acties gaan per page) maar veel veiliger. Denk wel dat je veel meer fragmentatie krijgt maar goed je SQL database ga je hier sowieso niet opzetten dus dat komt allemaal wel goed
Het wordt eens tijd, voor Linux/Unix zijn er al lang veel betere bestandssystemen dan het verouderde NTSF. Ook met journaling functie.
Als thuisgebruiker blijf je dus vooralsnog zitten met een antiek bestandssysteem.
Is er dan zoveel beters? NTFS kan op het moment nog aardig mee met de meeste huidige Linux/Unix filesystems. Ext4 en HFS+ zijn nog oudere, opgelapte filesystems, JFS wordt door niemand behalve IBM nog gebruikt, wat er met Btrfs gebeurt is nog maar de vraag nu Oracle 2 filesystems in huis heeft, en het ouwe trouwe XFS mist moderne metadata features. Een achterstand heeft Microsoft eigenlijk alleen op ZFS, en ik neem aan dat MS daarom juist met ReFS komt (zeker als ze met W8 Server een serieuze gooi gaan doen naar de lucratieve high-end Unix markt). Maar ook ZFS is een typisch server filesystem, voor thuisgebruikers heb je er niet zoveel aan, ZFS performt niet zo briljant en je zal best wel wat low-level werk moeten verrichten aan het OS. Apple heeft het niet voor niets afgekeurd als next gen file system voor OS X, en de Linux support is ook nog niet 100%. Niet dat het een slecht filesystem is, maar overschakelen is mega veel werk voor maar weinig winst, en de winst die je haalt in een betrouwbaarder filesystem gaat weer te niet door de onvermijdelijke nieuwe bugs in je filesystem driver. Dus zo heel veel keus heb je nog niet, en als er geen noodzaak voor nieuws is, dan wil je (ook als thuisgebruiker) liever de proven track record van een NTFS dan "bleeding edge" filesystem wat 99% af is, hoe mooi het ook op papier eruit ziet.

Verder zal het Microsoft weinig schelen, MS voelt uiteraard weinig voor om voor de toekomst van hun filesystem afhankelijk te zijn van een Oracle (ZFS), IBM (JFS), Google (ext4, tegenwoordig) of Apple (HFS+), en hoe blij zou de open source community worden als Microsoft een project als ext4 zou gaan adopteren en het op eigen houtje moderner maken (dingen als B+ trees toevoegen)? Ik kan me de reacties nu al voorstellen... Er verandert weinig, MS bouwt gewoon zijn eigen filesystems als ze die nodig hebben.

[Reactie gewijzigd door Dreamvoid op 18 januari 2012 01:07]

Dat zullen veel mensen niet met je eens zijn.
NTFS is namelijk het oude filesystem, dat in 2000 geÔntroduceerd werd als 'new' en 'built from the ground up', maar was eigenlijk een verbetering van HPFS. Dit bestandssysteem was ontworpen voor OS2 in 1986.

NTFS kan helemaal niet meer mee, want het levert waardeloze prestaties als je het vergelijkt met andere journaling file systems, zoals ext4.
Ext4 is zeker geen 'opgelapt' bestandssysteem. Het is niet eens versie 2.0 van ext3. Het is wel backwards compatibel met ext3. Het ontwerp van ext4 stamt uit 2006 en in 2008 werd het standaard aan de linuxkernel toegevoegd. Waarom? Omdat het zo snel was en alle tekortkomingen van ext3 en XFS had opgelost.
Als Wikipedia weer online is, dan kun je dat zelf wel checken.

Ik zou je een hele benchmark kunnen laten zien, maar als ik de reads en de writes op mijn machine (AMD X3 Phenom II, Seagate Barracuda 7200.9) vergelijk, dan zie ik performanceverschillen van gemiddeld 20%. Schakel de cached writes uit en NTFS is helemaal hopeloos verloren. Verschillen tot wel 50% zijn dan normaal, afhankelijk van de volumes en de bestandsgrootte.
dan wil je (ook als thuisgebruiker) liever de proven track record van een NTFS dan "bleeding edge" filesystem wat 99% af is
Wat is er dan 99% af? FAT en NTFS wil nog weleens in de soep draaien. Dat heb ik bij ext4 nog nooit gezien.
Het enige nadeel dat ik heb kunnen ontdekken aan ext4 is dat dit bestandssyteem niet ondersteund wordt door Microsoft producten. Met progjes als ext2fsd kun je dan wel lezen, maar geen gebruik maken van de betere featues (extents enzo) van dit bestandssyteem. Jammer. Een gemiste kans voor Microsoft.

[Reactie gewijzigd door mrlammers op 18 januari 2012 16:51]

Zo antiek is NTFS nu ook weer niet. Vergeet niet dat het in de loop der jaren best wel de nodige updates gehad heeft. De NTFS zoals hij nu draait is niet de NTFS zoals hij in NT4.0 zat.

En laten we eerlijk wezen, voor 99,99 procent van de thuisgebruikers voldoet NTFS uitstekend.

Als je naar verouderde filesystems wil kijken, neem dan FAT/FAT32 ofzo, dŠt is inmiddels ťcht verouderd.
het verouderde NTSF.
NTFS kent allerlei versies en wordt zo'n beetje met elke nieuwe kernelversie van windows geupgrade. Het is dus niet zo verouderd als jij wel denkt.
Da's dan vooral de filesystem driver, het on-disk formaat van NTFS is sinds XP niet meer veranderd.

(in de praktijk kan je die 2 niet los zien, een goed filesystem is waardeloos zonder betrouwbare/snelle driver, en omgekeerd. Met een goede driver kan je een in theorie 'verouderd' filesystem toch best aardig laten presteren, zie OS X)

[Reactie gewijzigd door Dreamvoid op 17 januari 2012 19:43]

Conclusie: een (groot) deel van de op schijf opgeslagen bestanden het OS is alsnog vatbaar voor corruptie omdat het niet van een ReFS-schijf mag starten?
Vind het wel prima dat dit alleen in de servereditie zit, als consument zitten de meeste mensen niet zo te wachten op de overhead die dit met zich mee zal brengen. Voor simpele servers is dit een mooi alternatief voor RAID; ik vraag me echter af of dit FS nog support biedt voor RAID?
Geen alternatief voor RAID: als je disk crasht, can ReFS er niets meer mee aanvangen. Als 1 disk crasht in vb. een RAID5 of zelfs een RAID1, is er geen probleem.

Wel is het een beetje grappig dat een stroomuitval geen problemen meer oplevert: ik zou verwachten dat de servers op een UPS staan, en dat een onvoorziene stroomuitval zich uberhaubt niet kan voordoen (idealitair: dual redundant powersupply, elk naar een ander UPS).
ReFS kan met zogenoemde "storage pools" werken. Raad eens wat die kunnen doen? Die kunnen volumes over meerdere schijven spannen, waarbij een soort RAID5 gecreerd kan worden.
nee het spannen alleen is niet genoeg, wat vaak wel kan is dat er rekening mee word gehouden dat een schijf kan uitvallen en dat de bestanden dus op meerdere schijven word gekopieerd. Echter dit neemt natuurlijk meer ruimte in dan dat je bij een raid 5/6 verliest.
Leuk verhaal, maar in de praktijk moet er wel eens onderhoud aan de 'andere' kant van de UPS gebeuren (zeker in datacenters).

Heb het wel meegemaakt hoor, dat een of andere hapsnurker 180V op de lijn zet in plaats van 220V ... *pok* *POK* *PAF* daar gaan je geschakelde voedingen. Na 5 ontplofte voedingen toch de stroom maar weer uitgezet en we zagen het laatste kringeltje rook door de airco verdwijnen.

Kan je nog een UPS hebben maar onhandigheid overwint alles, zelfs redundant powersupplies.
Dat is net een situatie waar de UPS zijn taak perfect zou moeten vervullen. Inkomend voltage wordt gereguleerd (bij mijn UPS tussen 170V en 280 V, daarbuiten schakelt hij over op exclusief batterij), eventuaal overgegaan op batterij, en een propere shutdown is mogelijk. Dus hoe je met een ontplofte voeding kunt zitten als je 180V op de lijn krijgt op een toestel met UPS (of zelfs met een "gewone" regulator) is mij een raadsel. Dan zou al iemand met de instellingen van de UPS moeten zitten rommelen (hoewel de meeste UPSen niet zomaar een ander outputvoltage aankunnen).

Ik vermeld ook specifiek redundante voedingen, aangesloten op een verschillende UPS, en dan nog eens aangesloten op een ander circuit (dat laatste had ik niet vermeld), anders is een redundate voeding nogal zinloos (en zou het enkel een defect in een voeding opvangen). Maar ik besef wel dat voor veel toepassing een dergelijke ontdubbeling gewoon de investering niet waard is.
Veel bedrijven werken met clusters voor bedrijfskritische applicaties. Op het moment dat clusternodes de onderlinge communicatie verliezen wil je dat de onbereikbare server gestopt wordt om te voorkomen dat zaken dubbel worden uitgevoerd. Dit gebeurd vrijwel altijd door simpelweg de stroom van de server te halen. Oftewel een server stuurt een signaal naar de ups / fencing device om de andere uit te zetten.

Dus ja veel servers zitten op een UPS maar dat wil niet zeggen dat de stroom nooit plotseling wordt uitgeschakeld.
Heb jij ooit een cluster van dichtbij gezien? Ik alvast wel en dat op verschillende platformen, en ik moet nog steeds de eerste tegenkomen die botweg een node power shutdown doet waneer een node geÔsoleerd geraakt.

Stellen dat dit vrijwel altijd gebeurt via een power commando is dus zeer zwaar door de bocht. Michien dat er ergens een systeem bestaat die dat doet, maar ik zou zeker nooit zo'n systeem willen

[Reactie gewijzigd door Yalopa op 18 januari 2012 06:24]

Ik heb meer het idee dat het OS nodig is om gebruik van dit bestandssysteem. Waarschijnlijk moet er eerst nog software geladen worden voor het werkt. (tijdens de boot natuurlijk)
Dat lijkt me wel, als ik deze twee punten zo zie:

RAID:
Q) What about RAID? How do I use ReFS capabilities of striping, mirroring, or other forms of RAID? Does ReFS deliver the read performance needed for video, for example?

ReFS leverages the data redundancy capabilities of Storage Spaces, which include striped mirrors and parity. The read performance of ReFS is expected to be similar to that of NTFS, with which it shares a lot of the relevant code. It will be great at streaming data.
Als je een storage pool gebruikt, heb je hierin in feite een soort van RAID. Je hebt dan onderliggend geen hardware-raid nodig, hoewel dit de betrouwbaarheid wel verder doet toenemen.

Vervallen punten:
Q) What semantics or features of NTFS are no longer supported on ReFS?

The NTFS features we have chosen to not support in ReFS are: named streams, object IDs, short names, compression, file level encryption (EFS), user data transactions, sparse, hard-links, extended attributes, and quotas.
Ik vraag me af hoe de implementatie hiervan zich in de dagelijkse praktijk zal gaan verhouden. Hard-links, quota, encryptie en compressie zijn toch geen nauwelijks gebruikte zaken lijkt me. Als het file system dit zelf niet meer ondersteund, betekent dit dan dat je deze opties geheel niet meer kunt gebruiken, of is hier een andere oplossing voor? Het ontbreken van hard links lijkt mij inherent aan het ontwerp, maar quota en encryptie?
Encryptie kan je zowel een laag hoger (binnen het file format) als lager (whole disk encryption) doen, quota ook, het is een beetje onzinnig om hard links en symbolic links allebei te hebben, en een database zal bv zijn eigen compressie gebruiken, niet op filesystem niveau - ik denk dat Microsoft aan het bekijken is geweest of je een server filesystem wel vol moet proppen met features die performance schaden, en niet erg nodig zijn.

[Reactie gewijzigd door Dreamvoid op 17 januari 2012 22:47]

Dat geldt voor ieder bestandssysteem.
ik vraag me echter af of dit FS nog support biedt voor RAID?
Nou...
... terwijl een volume zelfs een tredeciljoen, of 10^78 bytes groot mag zijn.
Wilde je een tredeciljoen op een enkele schijf stampen?

Keuze van filesystem staat doorgaans los van een onderliggende raid-structuur. Het maakt voor het filesystem niet uit (sterker nog: het zou geen verschil moeten zien) tussen installatie op een fysieke disk, of een logische disk via een raid array.
Je antwoord negeert dat het OS met dit filesystenm zelf schijven kan samenvoegen tot 1 volume zonder raid ondersteuning te gebruiken. Het is dus wel degelijk een relevante punt dat het OS ook onderliggend nog raid ondersteunt of niet
Conclusie: een (groot) deel van de op schijf opgeslagen bestanden het OS is alsnog vatbaar voor corruptie omdat het niet van een ReFS-schijf mag starten?
Ik denk dat binnen een bedrijf een server met een crashende OS HD van minder belang is dan een gecrashte schijf met daarop productiedata. De eerste is vrij makkelijk vervangbaar, de tweede niet.

[Reactie gewijzigd door the_shadow op 17 januari 2012 14:34]

OS HD draait vaak in raid 1, zo blijft productiedata ook toegankelijk als er een OS HD crashed
Had liever dat ze eerst WinFS zodanig hadden afgemaakt dat ik het had kunnen gebruiken. Volgens mij hebben meer gebruikers daar wat aan.
Volgens mij is dit de opvolger/doorontwikkeling van WinFS. Beiden geŽnt op een relationele database.
WinFS 2.0 ;)
WinFS was gewoon te riskant gezien de stabiliteit van harddisks om als filesysteem te gebruiken.
Wat er van WinFS over is zit nu in ADO.NET.
Wijzigingen in bestanden worden altijd op een andere locatie dan het origineel weggeschreven, wat datacorruptie in geval van een schrijffout moet voorkomen.
Je zult dus altijd minstens net zoveel vrije ruimte moeten hebben als het grootste bestand op de schijf?
Dit klinkt alsof ze een beetje van ZFS genomen hebben, een beetje van HFS+J en dat met een soort van LVM systeem op NTFS geplakt hebben... Nu zal dat technisch vast wel goed geregeld zijn, maar ik had bij de titel van het artikel op iets 'vernieuwends' gehoopt...
Het feit dat dit allemaal mogelijk wordt terwijl het bestandssysteem ook nog leesbaar moet zijn via NTFS vind ik toch redelijk vernieuwend.
Ik vind dat redelijk evil. Het houd je filesystem achter, veroorzaakt overhead en ik zie simpelweg niet in waarom ik dat ReFS volume waar server 8 zelfs niet eens van kan starten aan een XP bak zou moeten hangen bijv.

NTFS is oud, het zou IMHO echt geen kwaad kunnen als ze dat een keer zouden vervangen (niet updaten dus). Een van scratch ontwikkeld FS zal altijd voordelen hebben op 1 die backwards compatible moet zijn.
Het is complexer dan dat. Ze hebben de filesystem architectuur die windows nu hanteert met NTFS als uitgangspunt genomen om zoveel mogelijk backwards compatible te blijven.

Dat wil wel niet zeggen dat je windows XP een ReFS schijf kan lezen. Het bestandssysteem is echt compleet anders. De high level API's zijn wel gebleven

Cfr. "Code reuse and compatibility"

http://blogs.msdn.com/b/b...tem-for-windows-refs.aspx

[Reactie gewijzigd door masterpoi op 17 januari 2012 16:08]

NTFS is oud
Dat zeg je alsof het iets verkeerds is ;)

NTFS gaat al heel wat versies mee met telkens fikse veranderingen die wel stabiel blijven. Het kan probleemloos mee met de rest. Maar nog beter is niks mis mee.. nieuwer om het nieuwe is niet zinvol.
Stabiel is goed, daar heb je gelijk in. Maar niet journaling bestandssystemen is echt iets uit de jaren 80. NTFS kan zich gewoon niet meer meten met bestandssystemen in andere besturingssystemen. Er zijn talloze efficiŽntere bestandssystemen die ook nog eens stukken beter bestand zijn tegen corruptie ťn veel minder defragmenteren.
Maar niet journaling bestandssystemen is echt iets uit de jaren 80.
:? NTFS *is* een journaling fs, dit ReFS gaat juist een stap verder door journaling te vervangen door "write on allocate" te introduceren, evt met integrity streams. Dit is trouwens niet nieuw, en zit ook in ZFS.

[Reactie gewijzigd door Dreamvoid op 18 januari 2012 00:34]

Een van scratch ontwikkeld FS zal altijd voordelen hebben op 1 die backwards compatible moet zijn.
In theorie wel, in de praktijk betekent opnieuw beginnen vooral meer bugs en onverwachte performance bottlenecks.
Ik zie nergens dat je je schijf ook nog als NTFS kunt benaderen. Dat delen van NTFS hergebruikt zijn lees ik dan weer wel.
In de informatica wereld doe je niet graag iets al te nieuws in veel gevallen. Als je uit oude en bekende brokstukken iets nieuws kan maken dat precies is wat je wil, waarom iets nieuws maken? Krijg je alleen hoge ontwikkelingskosten van.
Maar is ReFS nog steeds net zo vatbaar voor fragmentatie als NTFS?
NTFS is nauwelijks vatbaar voor fragmentatie.
Hoe kom je daar nu bij? Als ik niet maandelijks defragmenteer is het gemiddelde aantal fragmentaties per bestand 3! Dat vind ik nogal wat...
fragmentaties per bestand 3! Dat vind ik nogal wat...
Bewijs eerst maar eens dat je het merkt in de performance.

--
NTFS is oud, maar daarmee nog niet slecht. Een automobiel met een verbrandingsmotor is ook oud en toch heeft men die nog immer. Uiteraard zijn beide regelmatig vernieuwd en daardoor nog steeds goed bruikbaar..
Volgens mij is het belangrijkste zinnetje van deze post:

"Niet alleen de data zelf, maar ook metadata als directory-structuren wordt in tabellen in deze B+ trees weggeschreven."

Zou dit inhouden dat het een soort database based file system is zoals LinFS en/of WInFS? Is dit stiekem niet gewoon WinFS? Een SQL gebaseerd file systeem op basis van een NTFS laag?

Ik vraag me af wanneer ReiserFS weer eens uit de kast gehaald gaat worden..

[Reactie gewijzigd door Pruttelpot op 17 januari 2012 22:24]

B+ trees zijn niet nieuw, die zitten naast in (SQL) databases ook al jaren in filesystems. Maar het is niet zo gek dat allerlei features van het WinFS project langzaamaan geintroduceerd worden, er zijn natuurlijk lessen getrokken uit dat 'prototype' wat wel en niet werkt.

ReiserFS, dat weet ik nog niet zo. Inmiddels hebben ext3 en ext4 veel van de features gekregen, zijn ZFS, JFS, HFS+ en Btrs er ook nog (met support van grote bedrijven), en werken er nog maar heel weinig mensen aan.

[Reactie gewijzigd door Dreamvoid op 18 januari 2012 00:48]

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True