Microsoft geeft details Windows Server 8-bestandssysteem vrij

Reacties

« 1 2 »

Door Gulftown, dinsdag 17 januari 2012 14:15

Goed dat ReFS ook corrupte bestanden automatisch repareerd, dit kan heel erg handig zijn. Wat meer info over ReFS: http://en.wikipedia.org/w...Server_8#ReFS_file_system

[Reactie gewijzigd door Gulftown op dinsdag 17 januari 2012 14:24]

Door Blackarrownl, dinsdag 17 januari 2012 14:17

nu moeten wij er nog speciale tools voor gebruiken.
bijv. voor corrupte RAR bestanden

Door .oisyn, dinsdag 17 januari 2012 14:32

Die je downloadt van nieuwsgroepen bedoel je? Daar gaat dit nieuwe FS je dus echt niet bij helpen, want dan zijn er wel meer schakels dan louter een filesystem tussen jou en waar de file vandaan komt.

[Reactie gewijzigd door .oisyn op dinsdag 17 januari 2012 14:41]

Door Niemand_Anders, dinsdag 17 januari 2012 14:40

Je moet overigens wel het origineel gehad hebben. Het werkt dus niet met corrupte RAR bestanden welke je vanaf usenet download of zo. Want dan mis je de meta data.. Maar ReFS werkt ook met parity meta data zoals PAR dat ook doet. Alleen nu wordt die parity informatie in de meta data van het FS bewaard..

Het verplaatsen van het bestand bij wijzigingen helpt daarbij ook om defragmentatie te voorkomen. Echter vraag ik me wel af hoe dat performance technisch zit in het geval van een zware webserver waar de log bestanden continue stevig blijven groeien. Wordt het dan bijvoorbeeld een best practice om de bestanden voortaan elke uur te roteren zodat je minder grote bestanden continue aan het verplaatsen bent?

Door Reinstein, dinsdag 17 januari 2012 15:10

Het verplaatsen van het bestand bij wijzigingen helpt daarbij ook om defragmentatie te voorkomen. Echter vraag ik me wel af hoe dat performance technisch zit in het geval van een zware webserver waar de log bestanden continue stevig blijven groeien. Wordt het dan bijvoorbeeld een best practice om de bestanden voortaan elke uur te roteren zodat je minder grote bestanden continue aan het verplaatsen bent?

Misschien kun je het file systeem hinten om wat voor type bestand het gaat. Overigens moet de betreffende software daar dan wel gebruik van maken. Zou wel een mooie feature zijn

Door tympie, dinsdag 17 januari 2012 15:17

Ik neem aan dat het bestandssysteem schijfruimte alloceert in blokken / pages (eventueel met variabele grootte), en een bestand op schijf dus één of meerdere pages inneemt. En dat bij wijzigingen niet het hele bestand opnieuw geschreven / verplaatst wordt, maar slechts het gedeelte waarin de wijziging plaatsvindt.
In dat geval hoeven er dus niet continu potentieel grote files verplaatst te worden bij wijzigingen, maar slechts kleinere blokken. Wat natuurlijk dan wel weer tot fragmentatie kan leiden...

Door Dreamvoid, dinsdag 17 januari 2012 22:37

Als je de boel later weer defragmenteert (gedurende idle momenten) dan hoeft dat niet zo erg te zijn.

Door Shadow, dinsdag 17 januari 2012 14:22

Door Gulftown, dinsdag 17 januari 2012 14:24

Door Ferti, dinsdag 17 januari 2012 14:28

Goed dat je alert bent op de links waarnaar verwezen wordt, hier is overigens niets mis mee. Zie hier voor meer informatie over het inkorten van URL's via bit.ly.

http://en.wikipedia.org/wiki/Bitly

(Wel vóór morgenvroeg 6.00u lezen, daarna gaat Wikipedia op zwart

)

Door .oisyn, dinsdag 17 januari 2012 14:37

hier is overigens niets mis mee

Waar is niets mis mee? Met bit.ly? Hoe is dat relevant dan? Waar het om gaat is dat je niet makkelijk kunt zien waar de URL naar verwijst. Het is niet nodig om een URL in te korten voor je 'm op een forum of nieuwssite plaatst (Twitter is een ander verhaal uiteraard, al doet die dat tegenwoordig ook gewoon automatisch), en ik vind het zelfs ronduit onbeschoft als je 'm expres voor die reden in gaat korten. Je zegt zelf dat het goed is dat je er alert op bent; op het moment dat er een ingekorte URL staat kun je er dus niet meer alert op zijn. Ja, natuurlijk zijn er methoden om 'm te achterhalen zonder de link daadwerkelijk te bezoeken, maar dat is alleen maar extra moeite voor de lezer. Als je 'm dus ergens anders vandaan hebt is het wel zo netjes om 'm eerst zelf even te expanden voor je 'm post. Gulftown heeft dat uiteindelijk ook gedaan, waarvoor dank.

[Reactie gewijzigd door .oisyn op dinsdag 17 januari 2012 14:38]

Door swel, dinsdag 17 januari 2012 15:24

niet relevant idd om 'm in te korten en blijkbaar vinden mensen dat heeel eng. Als het goed is heb je beveiligings software.. Zoo eng zal het niet zijn. Take a walk on the wild side hh

Door CUnknown, dinsdag 17 januari 2012 16:01

Leuk, leuk, Dit is nou precies de naïviteit waar zo'n beetje alle XSS attacks op berust zijn.

Door .oisyn, dinsdag 17 januari 2012 16:08

Wat jij niet lijkt te beseffen is dat het gewoon een vorm van respect jegens de lezer is om duidelijk te zijn waar je naartoe verwijst.

[Reactie gewijzigd door .oisyn op dinsdag 17 januari 2012 16:08]

Door DigitalExcorcist, dinsdag 17 januari 2012 15:26

Een mouse-over is ook zo lastig

Door .oisyn, dinsdag 17 januari 2012 15:37

Moet je wel de juiste extensions in je browser hebben draaien.

Door Rick2910, dinsdag 17 januari 2012 15:58

Je kunt ook een '+' achter de bit.ly URL typen, dan zie je eerst een Bit.ly pagina met de URL waarnaar verwezen wordt, incl. stats.

Door MrPan, dinsdag 17 januari 2012 23:09

Wel eens geprobeerd op een ipad ?

Door Neko Koneko, woensdag 18 januari 2012 10:22

Je kunt op een iPad toch ook wel een URL copy/pasten en aanpassen?

Door Netrunner, dinsdag 17 januari 2012 14:34

In hoeverre de wikipedia bron betrouwbaar is weet ik niet, maar ik heb via webcasts (vanuit ms devs) wel heel veel andere dingen gehoord.

Door goestin, dinsdag 17 januari 2012 15:29

Door player-x, dinsdag 17 januari 2012 15:38

Wat ik mij afvraag is of NTSF via een file conversie overgezet kan worden naar ReFS.

Of moet men een nieuwe volume aan maken.

Als ik naar mijn eigen 2008R2 server kijk, met +18TB R5 volume, zou ik niet weten hoe ik zonder een NTSF naar ReFS zou kunnen gaan zonder een conversie, of een hele dure investering in een minimaal gelijke 2de volume.
(6x 3TB is 6x160=960 euro + ⁺/_-250 euro voor een controller)

Door abot13, dinsdag 17 januari 2012 17:02

als je ruimte over hebt binnen je NYFS volume, kan je het NTFS volume verkleinen een ReFS volume aanmaken en het zo verplaatsen, dat kan zelfs stukje bij beetje, waardoor je investering natuurlijk ook kleiner word. Maar idd een conversie tooltje zou veel handiger zijn en ik verwacht dat dit er ook wel komt.

[Reactie gewijzigd door abot13 op dinsdag 17 januari 2012 17:03]

Door player-x, dinsdag 17 januari 2012 22:11

Hmmm zou kunnen werken, maar voor ik dat probeer, ga ik dat denk ik eerst maar eens testen met een nieuwe stripe van 2x 3TB of zo, voordat ik daar mijn data aan ga blootstellen.

Door Amorac, dinsdag 17 januari 2012 18:01

volgens de FAQ op de blog zijn er geen plannen om een conversie tool te maken..

Door dasiro, dinsdag 17 januari 2012 22:41

Als dit over een bedrijfsserver gaat, dan is dat bedrag peanuts.
Als het over een homeserver gaat, why the hell zou je dan de moeite doen om te migreren? Zo'n hoeveelheid persoonlijke data gaat weinig tot geen meerwaarde hebben in een nieuw FS

Door humbug, woensdag 18 januari 2012 01:01

Dat is in serverland goedkoop.

Daarnaast zal je he volume offline moeten halen tijdens de conversie en een backup moeten maken. Er zullen vast wel conversie tools komen maar ik vraag me af wie er 18TB aan bedrijfskritische data gaat converteren zonder backup. Een flinke extra hoeveelheid schijfruimte lijkt dan ook onmisbaar. Maar in praktijk zullen de meeste partijen gewoon de server met ntfs laten draaien totdat het tijd is om de hardware te vervangen.

Door KaptKoek, dinsdag 17 januari 2012 20:17

Door niels.vries, dinsdag 17 januari 2012 14:18

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?

Door V_J, dinsdag 17 januari 2012 14:25

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).

Door EvilWhiteDragon, dinsdag 17 januari 2012 14:59

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.

Door abot13, dinsdag 17 januari 2012 17:05

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.

Door DigitalExcorcist, dinsdag 17 januari 2012 15:29

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.

Door V_J, dinsdag 17 januari 2012 23:27

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.

Door humbug, woensdag 18 januari 2012 01:12

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.

Door Yalopa, woensdag 18 januari 2012 06:23

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 woensdag 18 januari 2012 06:24]

Door Psycho_Mantis, dinsdag 17 januari 2012 14:27

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)

Door .oisyn, dinsdag 17 januari 2012 14:39

Dat geldt voor ieder bestandssysteem.

Door Eagle Creek, dinsdag 17 januari 2012 14:55

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?

Door Dreamvoid, dinsdag 17 januari 2012 22:43

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 dinsdag 17 januari 2012 22:47]

Door the_shadow, dinsdag 17 januari 2012 14:34

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 dinsdag 17 januari 2012 14:34]

Door abot13, dinsdag 17 januari 2012 17:07

OS HD draait vaak in raid 1, zo blijft productiedata ook toegankelijk als er een OS HD crashed

Door RefriedNoodle, dinsdag 17 januari 2012 14:43

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.

Door hAl, dinsdag 17 januari 2012 16:54

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

Door DigitalExcorcist, dinsdag 17 januari 2012 14:18

10 triljoen directories.

dir readme.txt /s ......

*36 jaar later*

Door roboreaper, dinsdag 17 januari 2012 14:24

over 36 jaar lach je om die hoeveelheden

Door zwippie, dinsdag 17 januari 2012 14:18

Ik dacht even dat er ReiserFS stond. De eigenschappen komen in ieder geval ook aardig overeen.

Door DigitalExcorcist, dinsdag 17 januari 2012 14:24

Behalve dat Steve Ballmer z'n vrouw niet heeft vermoord.

Bij wijze van spreken dan.

Door shredder, dinsdag 17 januari 2012 14:30

Vroeger stond er op Wiki een vergelijking van eigenschappen tussen verschillende bestandssystemen met in de laatste kolom "Murders your wife", erg grappig.

Zie hier nog een afbeelding:
http://www.flickr.com/photos/ronocdh/2651155110/

Door Titusvh, dinsdag 17 januari 2012 14:24

Had liever dat ze eerst WinFS zodanig hadden afgemaakt dat ik het had kunnen gebruiken. Volgens mij hebben meer gebruikers daar wat aan.

Door LooneyTunes, dinsdag 17 januari 2012 14:29

Volgens mij is dit de opvolger/doorontwikkeling van WinFS. Beiden geënt op een relationele database.
WinFS 2.0

Door masterpoi, dinsdag 17 januari 2012 16:10

Heeft er eigenlijk niks mee te maken

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

Door hAl, dinsdag 17 januari 2012 16:58

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.

Door pocketpc2003, dinsdag 17 januari 2012 14:25

De goede onderdelen zullen ook wel min of meer afgekeken zijn, natuurlijk.
Waarom moeilijk ontwikkelen als het makkelijk kan....

Door CiPHER, dinsdag 17 januari 2012 14:41

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).

Door CyBeR, dinsdag 17 januari 2012 14:58

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.

Door masterpoi, dinsdag 17 januari 2012 15:26

Lees

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

hoofdstukje

"Resiliency to disk corruptions"

Door tympie, dinsdag 17 januari 2012 15:27

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.

Door freaky, dinsdag 17 januari 2012 15:35

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.

Door Ramon, dinsdag 17 januari 2012 14:48

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.

Door johnkeates, dinsdag 17 januari 2012 14:54

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...

Door EvilWhiteDragon, dinsdag 17 januari 2012 15:02

Het feit dat dit allemaal mogelijk wordt terwijl het bestandssysteem ook nog leesbaar moet zijn via NTFS vind ik toch redelijk vernieuwend.

Door freaky, dinsdag 17 januari 2012 15:37

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.

Door masterpoi, dinsdag 17 januari 2012 16:07

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 dinsdag 17 januari 2012 16:08]

Door Dreamvoid, dinsdag 17 januari 2012 17:56

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.

Door SED, dinsdag 17 januari 2012 21:48

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.

Door s463042, dinsdag 17 januari 2012 23:54

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.

Door Dreamvoid, woensdag 18 januari 2012 00:24

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 woensdag 18 januari 2012 00:34]

Door latka, dinsdag 17 januari 2012 15:39

Ik zie nergens dat je je schijf ook nog als NTFS kunt benaderen. Dat delen van NTFS hergebruikt zijn lees ik dan weer wel.

Door Amanoo, dinsdag 17 januari 2012 15:15

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.

Door Dreamvoid, dinsdag 17 januari 2012 18:00

En onbekende performance.

Door mrlammers, dinsdag 17 januari 2012 15:16

bij stroomuitval bijvoorbeeld zou data op een server met ReFS niet verloren moeten gaan.

Ik concludeer hieruit dat write caching verleden tijd is?

Door freaky, dinsdag 17 januari 2012 15:45

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.

Door QQ2, dinsdag 17 januari 2012 17:15

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

« 1 2 »

Op dit item kan niet meer gereageerd worden.

14:24	'Sony werkt aan smartphones met extreem helder scherm'
13:50	'Apple gaat tool voor interactieve e-books aankondigen'

Nieuws I/O

Shortcuts

Categorieën

Lees meer over

Gerelateerde content

Gerelateerde jobs

Reacties

09:51 Nieuws

08:50 Productreviews

09:52 Vraag & Aanbod

25-05 Jobs

09:49 Etc.

10:00 Reacties

10:00 Forum

25-05 Gesponsorde acties

01:46 Tweakblogs

26-05 Computable headlines

25-05 CRN headlines