'Microsoft hernoemt Protogon-bestandssysteem naar ReFS'

Het nieuwe bestandssysteem dat Microsoft in Windows 8 zou willen integreren, zal mogelijk ReFS gaan heten in plaats van de huidige codenaam Protogon. Het nieuwe bestandssysteem is gebaseerd op een databasemodel.

Hoewel Microsoft officieel nog niets heeft losgelaten over het gebruik van een nieuw bestandssysteem, werd er al in juni, in vroege alfaversies van Windows 8, code aangetroffen die verwezen naar een Protogon-filesystem, onder andere in de vorm van een kernel mode-driver. Inmiddels meldt de website Winunleaked.tk dat het bestandssysteem in recente builds is hernoemd naar ReFS. De verwijzing naar het nieuwe bestandssysteem is onder andere te vinden in het dialoogvenster voor het formatteren van een volume.

ReFS zou gelijkenis vertonen met het Windows Future Storage-bestandssysteem dat volgens de oorspronkelijke planning van Microsoft in het toenmalige Longhorn, oftewel Windows Vista, zou worden opgenomen. WinFS zou gebaseerd zijn op een databasemodel met concepten als rijen, tabellen en transacties, en had tot doel om zoekopdrachten te versnellen. De ntfs-opvolger zou uiteindelijk echter niet in Windows Vista worden opgenomen en ook in Windows 7 is WinFS niet aanwezig.

Met de vondst van onderdelen van ReFS, dat overigens ook een ntfs-emulatielaag zou bevatten, in de laatste builds van Windows 8 zal Microsoft nu mogelijk toch de stap zetten om dit bestandssysteem op te nemen. Microsoft liet onlangs nog in een posting weten dat Windows 8 in ieder geval met volumes van 3TB en groter om kan gaan, mits de hardware dit ondersteunt. Daarvoor is onder andere een pc nodig met een recente uefi.

Reacties (130)

[Verwijderd]

Mooi!

Database gebaseerde bestandssystemen zijn de toekomst... eindelijk!

[latka]

Al eens geprobeerd om een hierarchisch (filesysteem) model in een relationeel model te stoppen? Dan weet je dat dit waardeloos is. Dus zo voor de hand liggend is het niet om alles in een DB te stoppen.
Het grootste probleem is nesting. Stel je kiest ervoor een tabel te maken met als naam "directories" en de records hierin bevatten foreign-keys naar de parent en child-directories. Als je dan 10 levels diep een directory in wilt moet je 10 queries uitvoeren (dus 10x naar disk). Dit optimaliseren kan dan wel weer, maar levert een draak van een db model op. Heb dit gezien met LDAP servers die een DB onderkant gebruikten: niet vooruit te branden totdat men overstapt op een niet relationeel backend en blijkt dat ook LDAP snel kan.

[cablepokerface]

Het nesting probleem is op te lossen door de nesting in ieder record bij te houden. De id van alle parents staan in een pivot tabel op volgorde opgeslagen, Das 1 query met een join. Ik heb het gedaan en het werkt.

Als je me nu zegt dat ik dan redundancy promote EN erg moet uitkijken bij mijn update scripts, dan heb je helemaal gelijk.

Maar het kan wel.

[DieDubbelJoe]

Wie heeft er gesproken over een relationeel databasemodel. Zoals je kan lezen in het artikel van een kleine maand terug zijn er wel nog andere modellen mogelijk (http://tweakers.net/reviews/2354). Maar ik heb inderdaad wel dezelfde bemerking, al geldt hetzelfde voor de huidige records in de MFT (Master File Table) hoor...

[PiepPiep]

Wat houd het eigenlijk in dat het database gebaseerd is? of is het misschien een buzzword zoals cloud wat lang niet altijd beter hoeft te zijn?

[berend_engelbrecht]

concepten als rijen, tabellen en transacties, en had tot doel om zoekopdrachten te versnellen

1. Het belangrijkste voordeel is de mogelijkheid tot sneller zoeken. Met de huidige bestandssystemen moet je meestal sequentieel door alle bestanden, dat is erg inefficient. Is het het je nooit opgevallen dat het veel langer duurt om iets op je eigen hard disk terug te vinden dan op het hele internet met google? En als je een search accelerator gebruikt zakt de performance van je computer weer in (google desktop was daar berucht om).

2. De rijen en tabellen zijn voornamelijk "nuts and bolts" van een databasemodel, die voegen niet veel toe als je een bestandssysteem wilt emuleren. Alleen dit: probeer het volgende eens in een huidige Windows-versie:
- Ga naar een map met veel foto's, zet de weergave op details
- Zet wat extra kolommen aan, bijvoorbeeld "Date Picture Taken" en "Dimensions"
- Sorteer op een standaardkolom, b.v. "Date Modified", kijk hoe lang dat duurt.
- Probeer dan te sorteren op een van de extra kolommen. Dat duurt veel langer.
Met een tabelstructuur is de "metadata" van het bestandssysteem beter uitbreidbaar te maken en zullen dingen als die extra kolommen veel soepeler kunnen werken.

3. Transacties: dat maakt recovery bij mislukte (of onbedoelde) acties beter mogelijk. Denk aan undelete.

4. Niet in het artikel genoemd: een databasemodel maakt versiemanagement beter mogelijk. Met versiemanagement wordt het mogelijk om na opslaan van wijzgingen ook nog vorige versies van een bestand terug te halen.

5. Ook niet genoemd: views. Een view is een soort "virtuele tabel" van records die eigenlijk fysiek anders georganiseerd zijn. Bijvoorbeeld je hebt een grote bak mp3's en je kan die ook als mappen per artiest, of per genre bekijken. De libraries in Windows 7 zijn daar een aanzet toe, maar het werkt niet lekker zonder een echte database er achter.

Ik heb geen idee wat er in ReFS moet komen, maar dit zijn zo'n beetje de pluspunten die in principe mogelijk zijn bij keuze voor database storage.

[Reactie gewijzigd door berend_engelbrecht op 26 juli 2024 05:38]

[M0N0]

Puntje 5 is het eenvoudigst te onderschatten... Het komt er inderdaad op neer dat mappen niet meer hiërarchisch opgeslagen dienen te worden in het bestandssysteem. Het cliché voorbeeld is wat jij al aangaf: muziekbestanden groeperen per artiest, genre, duur, decennium van verschijnen, ... in je explorer.exe kadertje. Maar dan niet omdat je explorer.exe CPU-tijd en RAM-geheugen verspilt om al je bestanden te filteren, maar omdat je filesysteem geïndexeerd is op al die "kolommen".

Waar ik echter op hoop is dat iemand slim (en dan niet T.net-stijl "technisch slim", maar "innovatief/creatief slim") eindelijk een manier vindt om een tag-gebaseerde aanpak voor bestandsbeheer te bedenken die effectief vlot aanvoelt. Want in een systeem zoals ReFS (of toch: zoals het beschreven wordt) duurt het even lang voor het systeem om "alle bestanden die door gebruiker XXX gemaakt zijn tussen YYY en ZZZ en die de labels AAA of BBB dragen" te vinden dan het voor pakweg FAT32 of NTFS duurt om "alle bestanden in C:\Users\XXX\Documents\YYY\" te vinden. De mogelijkheden zijn dus zéér uitgebreid, maar wat momenteel nog ontbreekt is een doel ervoor.

[-=bas=-]

1&2
Dit heeft enkel te maken met het feit dat de bestanden al volledig geindexeerd zijn.
Als je dit zou doen voor de bestanden op je harde schijf dan zou je ook razendsnel
kunnen zoeken en sorteren op allerlei parameters. Databases slaan uiteindelijk ook hun data maar gewoon op op een schijf.

3&4&5
Dit kon 20 jaar geleden al met de systemen van Novell.
Dat we dit nooit in Windows hebben gezien zegt meer over de innovatie bij Microsoft dan over het wel of niet hebben van database achtige opslag structuren.
Ook moet je je eens afvragen hoe vaak je inhoudelijk iets terugzoekt in bestanden op je schijf. 95% van de bestanden zijn systeembestanden dus totaal niet intressant voor de gebruiker. Dit alles had zonder problemen ook zonder een database-achtig opslag systeem gemaakt kunnen worden en enkel een database voor de indexering zou voldoende zijn. Windows probeert al van alles te indexeren sinds WindowVista maar de Microsoft developers weten het weer aardig te verpesten gezien de prestaties en overhead.

Database-achtige opslagsystemen waren/zijn helemaal niet nodig als Microsoft in de laatste 20 jaar misschien iets meer innovatie had toegepast op de kernel van Windows in plaats van de zoveelste grafische make-over van Windows/Office waar ik al helemaal niet op zat te wachten .

[Durandal]

2. De rijen en tabellen zijn voornamelijk "nuts and bolts" van een databasemodel, die voegen niet veel toe als je een bestandssysteem wilt emuleren. Alleen dit: probeer het volgende eens in een huidige Windows-versie:
- Ga naar een map met veel foto's, zet de weergave op details
- Zet wat extra kolommen aan, bijvoorbeeld "Date Picture Taken" en "Dimensions"
- Sorteer op een standaardkolom, b.v. "Date Modified", kijk hoe lang dat duurt.
- Probeer dan te sorteren op een van de extra kolommen. Dat duurt veel langer.
Met een tabelstructuur is de "metadata" van het bestandssysteem beter uitbreidbaar te maken en zullen dingen als die extra kolommen veel soepeler kunnen werken.

Dat heb ik werkelijk nog nooit hoeven doen. En ik heb al heel wat windows gezien.

3. Transacties: dat maakt recovery bij mislukte (of onbedoelde) acties beter mogelijk. Denk aan undelete.

Dat wil dus zeggen dat je je records bewaart. Moet je ze op een gegeven moment toch opruimen. Hoe is dat anders dan de trashcan?
Wat ik echter gek vindt is dat sinds NTSF undelete ineens een heel stuk moeilijker is geworden. Ik kan me Win95 en dos herinneren waar je het heel bont moest maken wilde je je files, inclusief map, niet meer terug kunnen halen.

4. Niet in het artikel genoemd: een databasemodel maakt versiemanagement beter mogelijk. Met versiemanagement wordt het mogelijk om na opslaan van wijzgingen ook nog vorige versies van een bestand terug te halen.

Niet vernieuwend hoor. VMS heeft dat al heel lang en er zijn ook andere versioning file systems in gebruik.

5. Ook niet genoemd: views. Een view is een soort "virtuele tabel" van records die eigenlijk fysiek anders georganiseerd zijn. Bijvoorbeeld je hebt een grote bak mp3's en je kan die ook als mappen per artiest, of per genre bekijken. De libraries in Windows 7 zijn daar een aanzet toe, maar het werkt niet lekker zonder een echte database er achter.

En daar zie ik het enig voordeel. En gelijk een nadeel, want je moet wel al die tags er aan hangen waar je voorheen er maar een (de folder) aan hoefde te hangen.
Wordt het dan makkelijker? ja, mogelijk, als je er de extra moeite voor over hebt.
Met wat geluk helpen automatisch gegenereerde tags in bepaalde omstandigheden. De tijd zal het uitwijzen. Ik sta vooralsnog niet te springen.

[Reactie gewijzigd door Durandal op 26 juli 2024 05:38]

[berend_engelbrecht]

Wat ik bedoelde te zeggen is niet dat dit nieuwe features of nieuwe ideeën zijn, natuurlijk niet. De vraag was: wat is het voordeel van een database als file system en ik wilde uitleggen welke bestaande functies met zo'n database beter geimplementeerd kunnen worden dan nu met NTFS.

1. Search spreekt voor zich, dat werkt buitengewoon slecht nu. Database engines (zowel Oracle als SQL Server) hebben vrij goede full text search engines ingebouwd. Overigens is die van Microsoft afgeleid van Index Server - de basis van Windows search, maar via de database kan je krachtiger en preciezere zoekopdrachten geven. Bijvoorbeeld zoeken op datum werkt slecht in stand-alone Index Server en is eenvoudig te maken met datumvelden in de tabel waar de bestanden zitten.

2. Het voorbeeld was bedoeld om te illustreren dat sorteren op custom kenmerken van bestanden nu weliswaar kan, maar slecht werkt. Wat ik beschrijf kan zeker al vanaf Windows 2000 (misschien al eerder, kan me niet herinneren of Windows 9x het kon), maar het werkt duidelijk veel trager dan bij de ingebouwde kolommen. Het punt is dat de properties van NTFS niet uitbreidbaar zijn, daarom moet bij het sorteren op een custom property elk bestand telkens opnieuw geraadpleegd worden. Dat maakt het traag.

3. Met een transaction log (Oracle: undo segment) zou je multi-step undo kunnen maken. Of ze dat ook gaan doen weet ik niet. Dat het log erg groot kan groeien klopt. Multi-step undo heeft nogal wat overlap met versiemanagement [4], dus het zou vrij overbodig kunnen zijn. De transaction is een concept dat vrijwel elk DBMS gebruikt om de integriteit van gecombineerde updates en parallele wijzigingen door verschillende clients te garanderen, misschien is dat een betere functie om te noemen.

4. VMS had versiemanagement, maar NTFS niet (tenminste niet native). Voor hun programmeertools gebruikt Microsoft TFS, dat gebruikt SQL Server als data layer. Ik kan me niet voorstellen dat dit niet iets is waar ze niet ook voor hun database file system naar kijken.

5. Libraries zitten al in Windows 7, dus ook een bestaande functie die beter kan. On the fly views maken is ook standaard in een DBMS, zou ik persoonlijk erg handig vinden.

[Reactie gewijzigd door berend_engelbrecht op 26 juli 2024 05:38]

[freaky]

Ben erg benieuwd naar hoe de search 'altijd' goed zou moeten werken.

Bijv. MP3's hebben in het bestand zelf tags staan. Dit zou betekenen dat het Filesystem hiervan op de hoogte moet zijn en deze tags ook in de database zou moeten opnemen. Dan zit je dus ook met synchronisatie als tags in het bestand gewijzigd worden (deze moeten weer bijgewerkt worden in het filesystem dan).

Voor de meest bekende bestandstypen is dat uiteraard nog wel te regelen. Maar hoe zit het dan met onbekende bestandsformaten?

[miniBSD]

Voor onbekende formaten kan alleen de naam van het bestand gebruikt worden.

En dan heb je nog geluk dat het lokaal staat. Zoeken op netwerkschijven is helemaal een ramp.

[Verwijderd]

Dergelijke bestandsparsers wil je ook echt niet in je kernel hebben trouwens...

[silentsnake]

Wat ik echter gek vindt is dat sinds NTSF undelete ineens een heel stuk moeilijker is geworden. Ik kan me Win95 en dos herinneren waar je het heel bont moest maken wilde je je files, inclusief map, niet meer terug kunnen halen.

Hoezo moeilijker? Omdat er geen standaard undelete tool wordt geleverd met het OS? Er zijn genoeg tooltjes die voor NTFS / ext2 / ext3 undelete functionaliteit geven. (Zie bijvoorbeeld UnEraser en ext3grep. )

Immers is het volgens mij nogsteeds zo dat de file alleen maar uit je partitie tabel wordt weggegooid en dat het niet fysiek verwijderd wordt. Alleen tja, als de blokken vervolgens overschreven worden door andere files heb je niks meer aan die tooltjes ...

[freaky]

Files staan niet in een partitietabel.

Het filesystem maakt er verwijzingen naar (pointers) die hebben overal zo'n beetje hun eigen naam. NTFS heeft de MFT (Main File Table) en ext bijv. inodes. De pointers worden inderdaad verwijdert, het bestand op zich niet.

Echter hoe complexer de filesystems worden, des te moeilijker voor een undelete tool om te achterhalen wat precies bij het bestand hoorde. In FAT had je gewoon een blok van X bytes en werd er (zoveel mogelijk) sequentieel geschreven, derhalve had je een goede kans dat de opvolgende blokken er ook bij hoorde. Als je undelete tool dan enige kennis van bestanden heeft (bijv. weet hoe een jpeg er uit hoort te zien, of een .doc bestand) dan kan dat vrij simpel.

Het wordt een stuk lastiger als je FS halverwege blok 1988414 begint waar ook al een stuk data van een ander bestand in staat en het dan potentieel ook nog hevig gefragmenteerd is.

Het is niet voor niks dat undelete steeds minder ondersteund wordt. Journaling en copy-on-write bijv. in nieuwe filesystems zou e.e.a. beter moeten maken zolang het filesystem consistent is, maar als je filetables / journals zwaar beschadigd zijn kun je weleens een serieus probleem hebben (backups maken is echt geen overbodige luxe, schijven kunnen ook kapot ).

[geert1]

Wil dit dan ook zeggen dat het voordeel zou hebben bij het opstarten, het laden van programma's / games en het algeheel werken met Windows?

[Verwijderd]

Database gebaseerde bestandssystemen zijn de toekomst

Voor de niet-geleerden onder ons.... waarom ?

[kimborntobewild]

Alleen om zoekopdrachten te versnellen.

[SuperDre]

tja, voor die paar keer dat ik een zoekopdracht gebruik.. Vraag is natuurlijk ook, is de performance in 'normaal' gebruik van die FS ook een stuk beter ten opzichte van bv NTFS, zoja, dan is dat mooi, zo nee dan komt het er bij mij niet op..

[freaky]

Meestal heeft het wat meer overhead. Ken ReFS niet dus ben eerder geneigd het met bijv. ZFS te vergelijken. Het biedt echter ook veel meer functies (ZFS dan) zoals bijv. copy-on-write, snapshots en andere leuke dingen als SSD's gebruiken als read-/write cache. Meeste van die functionaliteit is met name leuk op servers tho'.

Een feature van ZFS echter begint wel steeds belangrijker te worden. Checksumming, silent corruption op schijven is een steeds groter wordend probleem. In de engelse wikipedia over ZFS bevoorbeeld wordt melding gemaakt van een groot database systeem dat iedere 15! minuten last had van silent corruption.

[thegve]

Zijn niet alle/de meeste filesystems database gebaseerd?
http://en.wikipedia.org/wiki/Ext2#Inodes

Een Inode lijst representeert gewoon alle meta-data over een bestand.

[freaky]

In principe zou je inderdaad iedere filetable (of hoe je FS het ook noemt) een database kunnen noemen. Het is een beetje een onduidelijk nuance dingetje denk ik .

[habbekrats]

Create an MS-Dos startup disk

[arniejj]

Dat ze die optie nog niet eruit hebben gehaald.. Worden er tegenwoordig nog pc's verkocht met een Floppydrive? Ik vraag me af wat hedendaags het praktisch nut is van een 'MS-DOS startup disk'. Mocht je dat willen gebruiken dan laad je deze toch vanaf de installatie DVD?

[Michaelr1]

Het is nog vaak genoeg nuttig hoor, maar het is wel aan het uitsterven ja. Daarnaast kun je er ook gewoon UBS-sticks voor gebruiken.

[El Psycho]

Zou leuk zijn als die optie tegenwoordig een bootable stick kon maken, met een uitgeklede windows omgeving

[Simon Shipperd]

Daar kan je gewoon software zoals nlite voor gebruiken.

[i-chat]

met windows xp ja, met vista en dergelijke kan dat niet of iig niet zomaar, iets wat ms nog van linux zou kunnen leren, want in ubuntu kun je al bijna 2 jaar standaard een werkende cd versie van je huidige desktop maken....

[Bilel]

En Windows heeft deze mogelijkheden niet? Wel. Op verschillende niveaus zelfs. Je kunt met behulp van sysprep en imaging software gewoon je desktop op een bootable drive zetten. Zelfs op domein niveau kan je standaard-desktops uitrollen in je domein. Weliswaar niet zoals klein als Linux, maarja... die destro's zitten nog steeds met de "Alles moet op 1 CD"-hype. Want ja.. 700MB is ook echt duur.

[Blue_Entharion]

Weliswaar niet zoals klein als Linux, maarja... die destro's zitten nog steeds met de "Alles moet op 1 CD"-hype. Want ja.. 700MB is ook echt duur.

Voordeel hiervan is dat je het op een cd kan bakken, en dit in een oude pc zonder dvd drive (met CD natuurlijk) kan stoppen en dan werkt het gewoon... groter is niet altijd beter,

Een kleine usb stick kan ook natuurlijk. bij windows moet je nogal veel moeite doen om een bootable usb stick voor elkaar te krijgen helaas, veel gesukkel met dos prompts, files kopiëren of externe tools gebruiken...

Gestripte versies van linux draaien zelfs op kleinere apparaten zonder GUI, de volgende keer als jij een geautomatiseerd koffieapparaat gebruikt op het werk moet je je realiseren dat er een grote kans is dat daar linux op draait.

[Reactie gewijzigd door Blue_Entharion op 26 juli 2024 05:38]

[jGS]

Bovendien verschijnen veel distro's gewoon op DVD ...
Ik denk dat je zelf je kennis even moet aanscherpen

[T-men]

Want ja.. 700MB is ook echt duur.

"Duur" heeft er niets mee te maken. Door een limiet van 700MB aan te houden probeert (nou-ja probeerde) men de programmeurs de dwingen slanke en snelle software te maken. Het is een middel om overbodige crap van de CD te weren. "Van elke file moet nu echt overwogen worden of deze écht nodig is op de CD"

Da's een filosofie die op zich te prijzen is. Te meer omdat een gebruiker, wanneer hij dat wil, zelf eenvoudig (gratis ) ontbrekende pakketten kan downloaden.

Edit: link toegevoegd

[Reactie gewijzigd door T-men op 26 juli 2024 05:38]

[In Search of Sunrise]

met windows xp ja, met vista en dergelijke kan dat niet of iig niet zomaar, iets wat ms nog van linux zou kunnen leren, want in ubuntu kun je al bijna 2 jaar standaard een werkende cd versie van je huidige desktop maken....

Voor Vista heb je vlite. Voor 7 is er zoiets nog niet, tenminste niet van meneer Nuhagic.

[Reactie gewijzigd door In Search of Sunrise op 26 juli 2024 05:38]

[svenk91]

Dat heeft Microsoft al in de vorm van windows embedded standard, maar afzeiken is makkelijker dan je feiten leren natuurlijk.

[kimborntobewild]

Dan moet je een extra licentie kopen.

[Proxivire]

Ja, want waarom makkelijk doen als het moeilijk kan.

[Durandal]

Staat nergens dat het een diskette is. Zou zomaar een CD kunnen zijn.

[zyberteq]

Die mogen ze toch wel eens een keer weghalen, en puur via de cli mogelijk maken.

[Verwijderd]

Capacity: 29,9 GB. Dat is maar een klein schijfje!
En dan met blokken van 64 KB, niet echt goed als je veel kleine bestanden hebt.

[dasiro]

misschien wel in REFS

[PiepPiep]

Er zijn voor zover ik weet al bestandssystemen die kleine bestanden in de directories of andere locaties compact bij elkaar kunnen opslaan.
Databases als sql server en oracle werken trouwens ook met pages van een bepaalde grootte die veel groter zijn dan de minimale grootte van records, daar worden er ook meerdere samen in een blok opgeslagen.

[freaky]

Ja, o.a. reiserfs. Als ik het me goed herinner was dat een van de eerste. Data recovery in het geval van serieuze problemen wordt er echter niet makkelijker op (ieder voordeel heeft z'n nadeel zeg maar).

[catfish]

vermoedelijk een USB stick van 32GB

[Alexxxxxxxxxx]

Ben benieuwd hoe goed dit gaat werken met Linux.

[Dreamvoid]

Dat hangt van de community af, als die een fatsoenlijke driver schrijven dan goed. Anders...niet zo goed.

[cschutijser]

Dat is natuurlijk alleen mogelijk als de werking van het FS bekend is. Als er geen documentatie wordt vrijgegeven (wat we wel eens vaker gezien hebben bij Microsoft...) dan moet alles ge-reverse engineererd worden. En dat kost vrij veel tijd, zeker om een stabiele implementatie te maken.

[Dreamvoid]

Voor zover ik weet is de NTFS specificatie gewoon beschikbaar aan 3rd parties als je een licensie neemt. Zo doen bedrijven als Paragon en Apple het, en dat kan een willekeurige Linux developer ook doen.

[Reactie gewijzigd door Dreamvoid op 26 juli 2024 05:38]

[Kopje_Koffie]

Als je zo'n licensie afsluit krijg je de specificaties wel, maar je mag die waarschijnlijk niet openbaar maken. En je code kan je dan waarschijnlijk ook niet openbaar maken. Dan heeft de Linux community er natuurlijk niks aan.

Microsoft had toch ook een zo'n licensie constructie opgezet voor exFAT?
edit: nieuws: Microsoft introduceert licentiemodel voor exfat-bestandssysteem

[Reactie gewijzigd door Kopje_Koffie op 26 juli 2024 05:38]

[PiepPiep]

En zelfs als je de code niet vrijgeeft maar alleen de binairies wil dat niet zeggen dat er niet bijvoorbeeld voor elke copy daarvan een bedrag moet worden betaald.

[magistus]

Als de community de mogelijkheden krijgt om deze te _kunnen_ schrijven. Fatsoenlijke info vanuit Microsoft zou hierbij natuurlijk wel helpen...

[P-e-t-j-e]

Waarom zou je dit met Linux willen laten werken? Het is toch een Microsoft (Windows) bestandssysteem? Ik neem aan dat het voor netwerkshares geen verschil maakt.

De enige reden die ik kan bedenken is wanneer je een HD uit een windows machine onder linux zou willen mounten omdat je systeempje gecrashed is...

[Dykam]

Het delen van schijven tussen OS'n is ook vrij praktisch in dagelijks gebruik, vooral onder een dualboot setup. FAT is nu niet echt praktisch meer, met de limiet van 4GB per bestand. De ext drivers voor Windows zijn nou ook niet bepaald stabiel te noemen.

[Roland684]

Ik heb toch nog geen enkel probleem met de Ext2Fsd-driver onder windows gehad.

[PiepPiep]

Ik wel, het werkt toch altijd minder lekker dan een native ondersteunde filesystem.
Als ik een ext2 geformatteerde schijf of stick aansluit moest ik altijd een beetje klooien om hem zichtbaar te krijgen.
Dat is ondertussen wel misschien alweer een jaar geleden, maar die driver bestaat al veel langer.

[Roland684]

En je usb-stick dan? Blijven we daar mee op fat32 hangen?

Een dual-boot-opstellingen, USB-harddisks, allemaal situaties warabij het toch wel handig als je ook bij je data kunt als onder een ander OS als waar je het volume mee geformatteerd hebt.

[thof]

Microsoft kennende zullen ze niet in eens alle voorgaande file systems in de ban doen hoor en kun je dus zelf nog altijd je USB sticks op NTFS, FAT32 of FAT formatteren...

[dmystic]

ik kan meerdere redenen bedenken hiervoor:

dual boot als je een gedeelde data partitie wilt hebben
grote externe harde schijven(waar fat dus niet meer werkt)
jouw reden

en er zijn er vast nog meer

[poepkop]

Omdat het nu misschien al vervelend is dat je een keuze moet maken: Of ik formateer mijn usb-stick Fat32 en ik kan alleen maar bestanden van max 4gb erop zetten, of ik maak hem ntfs en ik kan vervolgens de stick alleen op Windows gebruiken.

Maar het zal me niks verbazen als MS straks met Win8 de plank volledig misslaat en dat het marktaandeel sterk zal terug gaan lopen.

[Verwijderd]

Maar het zal me niks verbazen als MS straks met Win8 de plank volledig misslaat en dat het marktaandeel sterk zal terug gaan lopen.

En dat zeg je omdat JIJ het vervelend vind een keuze te moeten maken als je een USB stick formatteerd (persoonlijk nog nooit ook maar een seconde over nagedacht trouwens)? Ik bedoel dat is tot nu toe je enige argument.

Maar ik zie dat je al plusjes hebt dus het zal wel aan mij liggen.

[TonnyTonny]

Eh ?

NTFS alleen op Windows..... Loop jij niet een paar jaar achter ?
Mijn Apple en mijn Linux machines hebben absoluut geen moeite met mijn NTFS geformateerde externe HD's en USB sticks.

Voor files > 4GB is NTFS eigenlijk het enige werkbare formaat voor verwisselbare media (Dual-layer DVDs en Blu-rays even daargelaten).

[Maxonic]

Omdat je vanuit Linux ook je Windows partities wilt kunnen lezen en beschrijven. Het gaat dus niet om Linux op een ReFS draaien, maar mensen met een dualboot installatie in staat stellen makkelijk bij hun bestanden te komen.

ReFS doet me trouwens aan ReiserFS denken. Zou de heer Reiser vanuit state prison een klusje voor MS geklaard hebben?

[Reactie gewijzigd door Maxonic op 26 juli 2024 05:38]

[BartOtten]

Ik dacht er ook gelijk aan. Naamgeving, functionaliteit, kernpunten...ze komen behoorlijk overeen.

[erikdenv]

Wat een onzin. Ik heb ook een dualboot en velen met mij.
Als ik zin heb om Starcraft 2 te spelen start ik Windows 7 op. Normaal werk in onder Gentoo Linux.
Als je een spel wilt doen ga je niet Windows draaien in een virtual machine, dat prformt niet.

[musje83]

Ik ben toch heel erg benieuwd hoe dit de OS-schaal in beweging brengt. Apple en Apple-gebruikers gaan al jaren prat op de (lichte) superioriteit van HFS ten opzichte van NTFS.

Wie heeft hier meer verstand van? Wat verwachten jullie op basis van de informatie tot nu toe? Welke merkbare verschillen t.o.v. NTFS en HFS zullen er zijn?

[Dreamvoid]

Er is een hoop beter aan OS X, maar ik geloof niet dat er veel Apple specialisten werkelijk beweren dat HFS+ een geweldig filesystem is, of beter dan NTFS. Nu bijna alle legacy zut van het oude Mac OS vervangen is, is HFS waarschijnlijk de meest ouderwetse technologie in heel OS X. Arstechnica gaf in hun Lion review een waslijst aan redenen waarom HFS zwaar verouderd is tov moderne filesystems. Er werd binnen de Apple scene gehoopt op ZFS, en de teleurstelling was groot toen dat niet met SL kwam. Dat is achteraf logisch (Oracle en Apple zijn duidelijk geen vriendjes meer), maar de noodzaak blijft. Maar Apple heeft geld en talent genoeg om een opvolger voor HFS te maken.

De alternatieven liggen niet voor het oprapen, Btrfs is ook al van Oracle (oh nee!), NTFS is natuurlijk al helemaal not done, Reiser4 lijkt volledig stilgevallen, ext is ook al zo'n oudgediende waar maar op doorgebouwd is, GFS is weer van een concurrent (Google)...

[Reactie gewijzigd door Dreamvoid op 26 juli 2024 05:38]

[Blokker_1999]

maar btrfs is open source en kan perfect gebruikt worden, ongeacht wie de hoofdontwikkelaar is.

[latka]

btrfs is gpl...

[Dreamvoid]

De huidige spec wel, maar het is toch lastig ontwikkelen voor de toekomst als je twee kapiteins op een schip hebt. Oracle zal het slecht trekken als Btrfs door Apple 'gekaapt' wordt (zie Java) en als er geen forks komen, wil Apple wel dat Oracle grotendeels de roadmap van hun filesystem bepaalt? Ik kan eigenlijk maar bar weinig open source projecten opnoemen die succesvol door twee grote concurrenten gezamelijk worden ontwikkeld. Als je naar bv browsers kijkt, zijn Apple en Google gewoon hun eigen open source browser begonnen ipv bij Mozilla aan boord te klimmen. En bij Samba is het al niet veel anders.

[Reactie gewijzigd door Dreamvoid op 26 juli 2024 05:38]

[Dr.Trunks]

Microsoft liet onlangs nog in een posting weten dat Windows 8 in ieder geval met volumes van 3TB en groter om kan gaan, mits de hardware dit ondersteunt. Daarvoor is onder andere een pc nodig met een recente uefi.
Om van te booten ja, zelfs windows XP ondersteunt dit soort grote partities/volumes als extra data schijf.

[Durandal]

En linux heeft er helemaal geem problemen mee, uefi of niet.

[MSalters]

Linux kan niet booten als de BIOS ronduit weigert om je schijf te lezen. Hardware (firmware) support is dus zeker nodig.

[Verwijderd]

Het BIOS weigert niet om grotere harde schijven te lezen, het kan alleen niet alle sectoren erop lezen (het kan enkel de eerste X sectoren lezen, waarbij X afhankelijk is van de leeftijd/versie van je BIOS).

[CAPSLOCK2000]

Eerst zien dan geloven, dit wordt al zo lang beloofd dat ik alleen maar een beetje dom kan lachen.

Ik geloof wel dat ze fundamenteel de juiste richting kiezen. Dat we uberhaupt zoiets als databases hebben geeft aan dat onze huidige bestandssystemen niet meer voldoen.

95% van de databases op de wereld is niet veel meer dan een domme key-value store. Dat soort applicaties gebruikt een database omdat het filesystem te langzaam is, maar eigenlijk hebben ze al die geavanceerde techniek helemaal niet nodig. Vandaar ook het grote succes van de NoSQL-databases.

Veruit de meeste van die projects zou prima toekunnen met "ieder record is een file" als het filesystem snel genoeg zou zijn.

Een ander voorbeeld is MySQL. Dat is de SQL-database die het minste op een echte database lijkt, maar wel super populair is.

PS. Ik zeg niet dat alle databases overbodig zijn, maar wel een hoop. De gemiddelde website heeft geen complexe database nodig maar gewoon wat snelle files.

[Ramon]

Alleen belooft MS hier niets, een website heeft uit een gelekte build een conclusie getrokken.

[Verwijderd]

Maar een database is (voornamelijk) snel omdat de database zoveel mogelijk in geheugen staat. Een database die volledige vanaf de harde schijf draait zal ook niet vooruit te branden zijn. Maar met een filesysteem is zoveel mogelijk in geheugen laden geen optie, hoogstens wat prefetchen.

Voordeel van een relationele database als FS zal toch vooral de relaties tussen files zijn, niet de snelheid. En ook dat indexeren veel makkelijker is, en dat de index gelijk is bijgewerkt bij het veranderen/aanmaken/verwijderen van een file.

[Verwijderd]

Ik weet niet precies hoe Windows dat recentelijk doet, maar linux cached wel degelijk zo veel mogelijk van het bestandssysteem in het geheugen, net zoals een database dat doet (maar goed, een bestandssysteem is natuurlijk gewoon een gespecialiseerde database, en ik snap dus niet helemaal waar dit artikel precies over gaat ).

[pieterdebie]

Hoe weten jullie eigenlijk dat het ReFS is en niet REFS?
Nu ik ben blij dat Microsoft hun bestandsindeling goed lijkt door te werken voor het in een release te stoppen.

[Neo_revisited]

Als je de link in "Inmiddels meldt de website Winunleaked.tk dat het bestandssysteem in recente builds is hernoemd naar ReFS" volgt dan zie je twee screenshots uit Windows 8 waar het filesystem ReFS wordt genoemd.

[stereohead]

Ben benieuwd hoe dit zal gaan.

Als voorbeeld, de invoering van ext4 heeft jaren geduurd/is nog steeds bezig. Voordat het echt stabiel en als 'standaard' werd verklaard.

Gaat dit niet veel kinderziektes opleveren?

[uqrax]

Mwah, WinFS was ook al sinds voor 2003 in ontwikkeling . Genoeg tijd gehad om inmiddels de kinderziektes eruit te halen, toch?

[Thief]

Ben benieuwd hoe dit concurreert met ZFS

[Sfynx]

Windows heeft inderdaad dringend een antwoord nodig op ontwikkelingen als ZFS en Btrfs.
Sowieso het checksums en self-healing gedeelte met redundant pooled storage, wat Windows voor kritieke file servers toch weer wat beter zou maken. De erbarmelijke staat van de software RAID van Windows is de enige reden dat er nog geavanceerde hardware RAID kaarten nodig zijn i.p.v. standaard HBA controllers.

[Reactie gewijzigd door Sfynx op 26 juli 2024 05:38]

[teigetjuh]

Euhm, Raid controllers zijn voor lokale storage, hba gebruik je met een san welke de raid functies ook implementeerd. Raid is ook niet van toepassing op een nas. Dat er een antwoord nodig is op nieuwe filesystemen mag wel duidelijk zijn, want ntfs is toch ook al weer ruim 18 jaar oud. 18 jaar is wel bejaard in de it-wereld. Overigens ben ik wel eens met je stelling dat software raid belabberd is op windows, terwijl dit wel goed geregeld is op unix/linux.

[Sfynx]

Ik bedoelde te zeggen dat je geen RAID-controllers meer nodig hebt als je besturingssysteem zelf een fatsoenlijke RAID implementatie heeft.

Dan kan je overal toe met een doodnormale schijfcontroller zonder RAID-logica (= HBA). Ook nog eens beter voor de portabiliteit als de controller later besluit te overlijden.

Hardware RAID controllers zijn ingehaald door de combinatie van goede software RAID en de tegenwoordige snelle host CPU's en sloot aan PCI-E bandbreedte.

[Reactie gewijzigd door Sfynx op 26 juli 2024 05:38]

[TMDevil]

Sorry, maar RAID berekeningen laat ik liever over aan een "gespecialiseerde" en niet aan me x86 processor. Die processor heeft het al druk genoeg.

[Sfynx]

Hoeveel procent van de verwerkingskracht van een moderne server CPU gaat op aan RAID berekeningen? We praten over enkele procenten als het niet nog minder is. En als het echt zo'n probleem is, dan neem je een CPU modelletje hoger en het verschil in kloksnelheid geeft meer verwerkingskracht erbij dan zo'n hele RAID kaart kan leveren.

ZFS vraagt meer van de host CPU door de extra checksumberekeningen en ingebouwde compressie en self healing e.d., maar dat is iets wat hardware kaarten sowieso niet aan boord hebben (althans niet de kaarten die ik gezien heb)
Dus ik laat RAID liever over aan een implementatie als ZFS, data-integriteit gaat immers altijd voor snelheid (een systeem met de gewenste performance is makkelijk zat geregeld)

[Reactie gewijzigd door Sfynx op 26 juli 2024 05:38]

[SED]

belangrijker lijkt me dat alles op een cpu en mem draaien een extra probleem gaat opleveren als daar iets fout gaat. Dan gaat je raid namelijk ook onderuit en ben je alsnog alles kwijt.
Vandaar kiezen voor hardware raid.
voorkom je voor een paar euro een SPOF

[Sfynx]

belangrijker lijkt me dat alles op een cpu en mem draaien een extra probleem gaat opleveren als daar iets fout gaat. Dan gaat je raid namelijk ook onderuit en ben je alsnog alles kwijt.
Vandaar kiezen voor hardware raid.
voorkom je voor een paar euro een SPOF

Als je CPU en RAM niet willen meewerken is alles sowieso verloren, de gegevens moeten ook van en naar die RAID-controller. En de hardware RAID kaart zelf is dan net zo goed een SPOF. En kan iets als ZFS dan niet meer iets corrigeren omdat deze geen controle meer heeft over de individuele volumes.

Natuurlijk heb je altijd off-site backups omdat er altijd iets met de gehele server kan gebeuren in extreme situaties.

[Reactie gewijzigd door Sfynx op 26 juli 2024 05:38]

[freaky]

Ah ZFS is een mooie (zie m'n andere post). Hier kun je het write caching probleem immers ondervangen met door een snelle SSD aan de ZIL toe te kennen.

Echter... veel OS'en ondersteunen geen ZFS . En als je iets hebt dat sync writes doet is caching toch wel redelijk belangrijk voor de performance.

[i-chat]

sorry maar ik neem liever en extra generieke x86 core die bij weinig schijf activiteit ook elders ingezet kan worden dan een propretaire specialistische chip die als de vendor kapot gaat zorgt dat je nooit je data meer kunt terughalen zodra je schijfcontroler er ook mee kapt..

natuurlijk heb je backups, maar enkele tb aan data uit je backups trekken omdat je je raid controller niet meer kunt vervangen.... tnx doe dan maar software raid...

[oliveroms]

raid1 en raid10 berekeningen zie je niet eens in je CPU load tegenwoordig. Raid5 is een paar procentjes, nauwelijks tot niet merkbaar.

[coolsmoe]

Als je bedrijfs-server aan 100% CPU draait, ben je niet echt goed bezig... maar je hebt het waarschijnlijk over je 'thuis-servertje' aka linux op je oude 386.

[latka]

Hoezo? Als het precies 100% is zou ik zeggen: perfect (mits je uitwijk maar op 0% staat ;-)

[coolsmoe]

Nah, niet echt, hangt er een beetje vanaf of een 'duurdere' cpu niet beter is voor je stroomrekening. ;-)

[m_w_mol]

100% voor een bedrijfsserver, zoals coolsmoe aangeeft, is nooit wenselijk. Dit soort systemen moeten altijd schaalbaar blijven en vaak is het bereiken van een continue belasting van 80% al voldoende om de alarmbellen van de Capacity Manager te laten rinkelen.

[Reactie gewijzigd door m_w_mol op 26 juli 2024 05:38]

[freaky]

Ik bedoelde te zeggen dat je geen RAID-controllers meer nodig hebt als je besturingssysteem zelf een fatsoenlijke RAID implementatie heeft.

Sorry, maar ik verga bijna van het lachen.

Simpel testje voor je. Pak een HP server, gooi er ESX(i) op. Trek de batterij van de smartarray af (deze schakelt dan zelf de write caching uit, niet overriden). Ga iets serieus doen met een VM'tje.

Merk op dat schrijf performance zwaar belabbert is. Dit valt met name in ESX op door de sync writes die deze uitvoert.

Je hebt nu in principe een soortgelijke opzet als software RAID zonder caching.

Forceer write caching. Ga rustig een partij schrijven, merk op dat alles sneller is. Veel sneller (factor 20 of meer). Trek de stekker uit het stopcontact. Start de machine daarna weer op. Merk op dat je barst van de corruptie. Fijn he, write cache zonder backup.

Hang de batterij terug aan de smart array en besef jezelf dat RAID controllers wel degelijk hun voordelen hebben (zeker als ze battery backed zijn). Dit is de belangrijkste, CPU load e.d. spelen ook nog een rol.

[Verwijderd]

Je kan natuurlijk je hele server aan een batterij hangen voor zowat het zelfde effect in de meeste gevallen. Oh wacht, je had al een UPS...?

BTW: dit is uiteraard een "bug" in ESX, die bewust geen transacties gebruikt om sneller te kunnen zijn en er daarbij van uit gaat dat je op enterprise hardware draait (en dus een UPS en eventueel battery backed disk controllers hebt), waardoor dat risico enigszins verkleind wordt. En transacties zijn nu net één van de (potentiële) voordelen van een database die in de reacties bij dit artikel genoemd worden...

Nu kan ik wel zien dat een battery-backed disk controller nog een kleine extra beveiliging tegen data-corruptie kan zijn, maar ik zie niet goed in wat het voordeel is van de propriëtaire, ongedocumenteerde RAID in 'n controller te gaan gebruiken. Mocht die controller generiek zijn zodat je zelf het type RAID e.d. kan programmeren, zou het wel te overwegen zijn natuurlijk, zeker als die bijvoorbeeld ook nog eens een encryptie-layer heeft—wat veel meer CPU-belasting geeft dan software RAID.

[flippy]

niet, want ZFS draait niet op windows (server) systemen.

[Sjah]

icrosoft liet onlangs nog in een posting weten dat Windows 8 in ieder geval met volumes van 3TB en groter om kan gaan

Heftig artikel, staat me hoofd nu niet naar, wie vat het even samen? Ik begrijp dus dat op W7 installen en booten vanaf een 3tb not done is?

REFS: goeie naam, prima!

[Sfynx]

Met een GPT moet dat gewoon kunnen lijkt me. Minstens twee GPT partities maken, 1 kleine die genoeg bootcode bevat om een kernel van een NTFS-partitie te kunnen lezen, en 1 hele grote die de rest bevat. De bootcode leest de kernel en boot deze.. en daarna handelt de kenrel de rest af, mounten van filesystem(s), laden van drivers e.d.

Zo doet FreeBSD GPT bootloader het i.i.g, die plukt de kernel zo van een ZFS pool af met ondersteuning voor 64-bit LBA, zodat het hele /-filesystem vanaf dezelfde zpool gemount kan worden als je wil.
Zonder noodzaak voor iets als UEFI overigens, zolang je controller maar 3 TB schijven aankan.

[Keef]

Volgens mij is 2TB de max, tenzij je software installeert van de fabrikant(?).
Bij het ReFS wordt het standaard ondersteund.

[Cobalt]

2.19 TB is de max van MBR maar niet van GPT. GPT heeft een max van 9.4 ZB. Je kan echter alleen booten van GPT i.c.m. (U)EFI.¹

[Reactie gewijzigd door Cobalt op 26 juli 2024 05:38]

[PiepPiep]

Je kan bij GPT iets doen met een fake MBR.
Je maakt dan in de GPT en de fake MBR een partitie die binnen die eerste 2TB valt en vult de eventuele rest ruimte binnen de 2TB in de MBR met een partitie waar niets mee gedaan kan worden.