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

Microsoft haalt mogelijkheid om ReFS-volumes te maken uit Windows 10 Pro

Door , 233 reacties, submitter: NiLSPACE

Met de komst van de Fall Creators Update dit najaar haalt Microsoft de optie om volumes te maken met het Resilient File System uit Windows 10 Pro. Vanaf dan is dat alleen nog mogelijk met Windows 10 Pro for Workstations of de Enterprise-versie.

Windows 10 Pro-gebruikers die eerder al een ReFS-volume hebben gemaakt kunnen dat blijven gebruiken. Het aanmaken van nieuwe volumes kan na de update dit najaar echter niet meer. Die functionaliteit is vanaf dan voorbehouden aan Windows 10 Pro for Workstations.

ReFS is geoptimaliseerd voor grote volumes en bepaalde workloads. Het kan onder andere beter met grote datasets overweg dan ntfs. Het Resilient File System is een opvolger van ntfs en wordt door Microsoft al gebruikt voor Windows Server 2012 en 2016. Het verdwijnen van de mogelijkheid om ReFS-volumes te maken blijkt uit een lijst van functies die veranderen of wijzigen met de komst van de Fall Creators Update. Twitter-gebruiker Tero Alhonen ontdekte dat.

Microsoft introduceerde Windows 10 Pro for Workstations eerder deze maand. De Workstation-versie biedt onder andere ondersteuning voor maximaal vier processors en 6TB ram. In Windows 10 Pro is dat maximaal twee processors en 2TB werkgeheugen.

Update, woensdag: Eind juni heeft Microsoft al de ondersteuning voor ReFS uit OneDrive gehaald. Dat meldt tweaker job_h. Ook andere gebruikers klagen daarover op de Microsoft-website.

Julian Huijbregts

Nieuwsredacteur

22 augustus 2017 21:03

233 reacties

Submitter: NiLSPACE

Linkedin Google+

Reacties (233)

Wijzig sortering
Hoe kan het een opvolger van NTFS (met hoofdletters) zijn als ik het niet meer kan gebruiken in plaats van...
Het is een heel gekleurd nieuws artikel. Hoewel we in de toekomst misschien wel ReFS gaan zien als standaard format heeft het nog een lange weg te gaan. Als eerste kan geen enkele besturingsysteem van Microsoft hiervan opstarten (ook server 2016 niet). Daarnaast is het alleen bedoeld als format voor specifieke (server) rolen zal hyper-v, Storage Spaces en sinds kort applicaties als Exchange (2016).

Echter is het allemaal nog optioneel en zal NTFS nog altijd nodig zijn als boot volume. Al deze zaken hebben niets met werkstations te maken en gezien de ontwikkeling niet zo hard gaan zal niemand het missen. Een aantal voorbeelden waarom NTFS momenteel nog hard nodig is:

The following features are unavailable on ReFS at this time:
Functionality ReFS NTFS
File system compression No Yes
File system encryption No Yes
Data Deduplication No Yes
Transactions No Yes
Hard links No Yes
Object IDs No Yes
Short names No Yes
Extended attributes No Yes
Disk quotas No Yes
Bootable No Yes
Supported on removable media No Yes
NTFS storage tiers No Yes

https://docs.microsoft.co...torage/refs/refs-overview
Maar waarom nu eruit halen? Zowel Hyper-V als Storage Spaces zitten in de client versie van Windows 10. Ja, het is nog in ontwikkeling. Daarentegen, de huidige versie is stabiel genoeg voor zelfs servertoepassingen. En het werkt hier al iets van 2/3 jaar probleemloos.
ReFS heeft heel wat fixes al gehad zowel in 2016 als 17, omdat er een aantal flinke problemen mee waren als je echt grote (zeg maar > 50TB) data sets gebruikte icm de standaard clustersize en op die data sets veel veranderingen waren. Nu is nog steeds de aanbevolen tactiek voor dit soort volumes voor een 64k clustersize gebruiken of anders duikt de performance naar beneden en die is al niet zo fantastisch.
Dus het is niet overal even stabiel voor helaas.

Wat mij het meest verbaasd is dat ReFS standaard alleen metadata checksumming doet terwijl ZFS met full checksumming over het algemeen zelfs sneller. Dat is echt een prestatie van formaat van MS.
Daarnaast heb je icm Storage Spaces minder SSD caching mogelijkheden om de performance wat op te krikken.
Wat je dan wel weer hebt is tiering met SSDs maar dat is niet real-time dus ook niet overal voor toepasbaar.

Wat ook echt nog niet OK is zie je wanner je ReFS op hotswap disks gebruikt en dan deze disks swappen voor andere (Bijv voor offsite backups) Je moet daarna 5-10 minuten lang wachten voor je Disk Management reageert en je de volumes kan mouten terwijl dit met NTFS vrijwel direct kan.

ReFS heeft bepaalde voordelen, zeker ReFS v2 uit Server 2016 icm Hyper-V omdat je dan snapshots (checkpoints in MS termen) kan verwijderen zonder dat die het hele volume eerst naar een nieuwe file hoeft te schrijven en je dus vrij ruimte nodig hebt ter grote van de disksize.
Maar op andere punten zijn er erg veel beperkingen en is de performance vergeleken met ZFS die meer checksumming doet nog slechter. Kortom genoeg werk aan te verzetten voor het echt volwassen is en we NTFS kunnen vergeten.
Lopen bestandsystemen die uit het linux wereldje komen ondertussen niet mijlenver voor op microsoft?

NTFS is ondertussel al iets van 20 jaar oud en niet zo nieuw meer (New Technology File System)
Nee. Het is niet voor niets dat AeroWB verwijst naar ZFS - dat is het belangrijkste moderne filesysteem, maar het komt uit de Unix wereld (Solaris om precies te zijn). Het gevolg van die achtergrond is dat ZFS niet onder de GPLv2 licentie van Linux valt, ook al is het Open Source.

Het gangbare filesysteem onder Linux is ext4, en dat is een incrementele verbetering van ext2/3. (Ext4 drivers snappen ext2 partities). Het nadeel van deze filesystemen is dat ze allemaal vast (moeten) blijven houden aan een "inode" structuur, wat eigenlijk een historisch implementatie-detail is.

btrfs is een Linux alternatief voor ext4, maar is lange tijd niet betrouwbaar genoeg geweest. Het lijkt er echter op dat het inmiddels wel stabiel is. Maar "stabiel" is nog niet " mijlenver voor"; stabiliteit is een vrij basaal iets.
Stabiel en mijlen ver voor zijn 2 verschillende dingen. Het een zegt iets over kwaliteit, het andere over features.

BTRFS is mijlen ver voor in features qua NTFS op vele gebieden. Dat gezegd hebbende, het is gemaakt voor data integriteit, copy on write, snapshots, mirroring, redundancy, etc. Qua performance zal het daarom waarschijnlijk nooit in de buurt komen van een ext4 gezien het veel complexer is. Daarentegen kan het bijv. wel bitrot ondervangen, kun je snapshots maken en beheert het filesystem zelf eventuele RAID waardoor het wat meer mogelijkheden t.a.v. bijv. reparatie heeft gezien het kennis heeft die een filesystem niet heeft als de RAID door een controller (of block layer zoals md) gedaan wordt en derhalve veelal niet kan zien waar het probleem zit.

XFS is ook erg gangbaar overigens en er zijn nog legio anderen
(ZFS, JFS, ReiserFS om er maar een paar te noemen).

[Reactie gewijzigd door freaky op 23 augustus 2017 10:35]

Ondanks dat btrfs flinke stappen heeft gemaakt, heeft redhat de hoop (voorlopig) opgegeven en is btrfs depricated voor RHEL8
https://access.redhat.com...ecated_Functionality.html
NTFS is gewoon verder ontwikkeld in die 20 jaar.
Wat mij het meest verbaasd is dat ReFS standaard alleen metadata checksumming doet terwijl ZFS met full checksumming over het algemeen zelfs sneller. Dat is echt een prestatie van formaat van MS.
Is dat sarcasme of ontgaat me hier iets?
AaeroWB lijkt het een hele prestatie van Microsoft te vinden dat ze het zo hebben kunnen vercopuleren, en daar moet ik hem stiekem wel gelijk in geven.
Dus inderdaad, sarcasme :)
Het is server functionaliteit en heeft dus onderhoud en support nodig (kosten). Kijk, ik wil Microsoft niet verdedigen maar ik begrijp het wel. Het draait immers allemaal om geld. Als zij bijvoorbeeld zien dat het maar weinig gebruikt wordt (en het wordt op servers al weinig gebruikt) dan verwijderen ze het.

Dat scheelt zeker in supportcalls omdat computerhulp Harry om de hoek denkt dat ReFS het beste is omdat het ‘nieuw’ is.

De meeste klanten die deze functionaliteit (Storagespaces en Hyper-V) echt gebruiken hebben wel een Volume Licence overeenkomt en kunnen gewoon Windows 10 enterprise installeren.
Dat is natuurlijk enigszins een onzinnig argument. Ten eerste moeten ze die code al onderhouden, of het nu voor 10 of 10M installaties is. Ten 2de krijgen ze normaliter niet veel support vragen als iets stabiel is en dat is sneller te bereiken met een bredere user base waardoor e.e.a. sneller ontdekt wordt.

Daarbij vertel ik Harry om de hoek liever dat ie z'n 2TB aan data kwijt is dan Shell dat ze hun 50PB+ kwijt zijn. Die eerste zal niet zo snel een claim weg leggen. Maar goed, wie ben ik.
In dat opzicht staat Apple al veel verder met zijn nieuw file system APFS.
-bootable
-metadata links en pointers (dus clones van data nemen geen extra plaats in, data kan gelinkt worden, je kan instant een file copy/pasten naar een andere plaats op de schijf)
- folder/file level encryption
- compression
- bootable
- mogelijkheid om meerdere file systems doorelkaar te gebruiken, geen nood voor een partitie met een vaste grootte.
- Ssd optimised, low latency acces.

Apple kan natuurlijk sneller migreren omdat ze geen enterprise servers hebben en bijna al hun devices gebruiken standaard ssd's.

Data pointers hebben volgens mij wel een invloed op de explorer/finder interface want je moet als gebruiker beseffen dat je de hoofdfile aan het aanpassen bent en dat al uw clones volgen.

Die metadata is wel hanig voor applicaties zoals indesign. Als je nu een gelinkte afbeelding in een andere map plaats is indesign zijn bronbestant kwijt. Met meta data kunnen apps deze files blijven 'volgen'.

Ik neem aan dat de Apple en Microsoft dezelfde optimalisaties nastreven. Dat zou zeggen dat de boot times gereduceerd worden met 10-20% en de data van een ouder file systeme 10% minder ruimte inneemt na de overstap. (Gemeten via de beta van High sierra)

Dus Apple gebruikers met 200Gb in gebruik zullen na de installatie van High Sierra 20Gb extra schuifruimte hebben.
https://www.google.be/amp...ers-with-space-speed/amp/

Ik veronderstel dat het bij Microsoft's ReFS niet anders zal zijn zodra het finaal is.

[Reactie gewijzigd door Coolstart op 22 augustus 2017 23:47]

Geen enterprise servers? Standard SSD?

Klopt helemaal niks van.

Data-deduplication en verschillende filesystems zijn bij MS ook geen probleem.

Ik snap niet wat je met je post wel zeggen.
Apple bouwt al geen Servers meer sinds 2004, dus nee geen servers, ook geen server OS. Apple server bestaat wel maar het is app en bijgevolg niet meer een management tool voor admins dan een enterprice OS zoals MS server dat is.

Standaard Ssd heb ik niet gezegd. Il zeg 'bijna allemaal'. Macbook, macbook
Pro's, iphone, ipads zijn enkel en alleen SSD. De nieuwe entry imac's hebben nog een HD maar met SSD caching dus ja bijna all hun devices worden verkocht met SSD.

Maar daar gaat het niet over. Ik zeg gewoon iets over de tegenpool van refs. Ik begrijp niet goed wat er zo absurd aan men post is.

Trouwens data-deduplication op ntfs is enkel voor file servers, niet voor boot drives, encrypted files etc. Ook niet beschikbaar op Windows 10 (pro). Dus je kan het niet 1 op 1 vergelijken.

[Reactie gewijzigd door Coolstart op 22 augustus 2017 23:40]

ReFS is al in ontwikkeling sinds de steentiijd maar niemand geeft daar een fuck om omdat NTFS goed genoeg is. De meeste van de "voordelen" van apfs die je noemt zijn al tientallen jaren aanwezig in NTFS (of elk halfweg modern FS)

Als een nieuw FS ergens "snel" gerealiseerd en gedragen is, dan is het wel de overgang van ext3 naar ext4 onder Linux. Wat Apple doet is niet zo boeiend, OSX is irrelevant vergeleken met Linux en Windows.
NTFS goed genoeg? Ik hoor het al, Het aantal keren dat dit filesysteem complete hard disken "verloor" tijdens performance testen van zo snel mogelijk lezen en schrijven van XML bestanden en dit bij te houden in een Oracle database, kan ik niet meer op 1 hand tellen.

De software waar ik aan werkte was zo snel dat na ongeveer 20 minuten logfiles dramatisch snel volliepen op de test computer, omdat de server (Windows 2008) een of meerdere drives verloor. Jawel, verdwenen uit de drive manager. Alleen na een volledige herstart verschenen de verloren drives weer.

NTFS kent een heleboel leuke kunstjes, maar het bestaat dan ook al 24 jaar. WinFS uit Windows Longhorn had al lang en breed uitgerold moeten zijn op Windows systemen. Bestandssystemen zijn niet bepaald het sterkste punt van Windows/Microsoft.
De software waar ik aan werkte was zo snel dat na ongeveer 20 minuten logfiles dramatisch snel volliepen op de test computer, omdat de server (Windows 2008) een of meerdere drives verloor. Jawel, verdwenen uit de drive manager. Alleen na een volledige herstart verschenen de verloren drives weer.
Het verdwijnen van disken klinkt meer als een probleem van de controller of de disk dan als een probleem van het file system.

[Reactie gewijzigd door The Zep Man op 23 augustus 2017 07:34]

Inderdaad, verdwijnen van disks heeft niets met het filesystem te maken. Ik bedoel ook zonder filesystem moet een disk gewoon altijd zichtbaar zijn.
Ik denk dat Apple het niet 'makkelijker' heeft met het uitbrengen van een nieuw bestandssysteem en met APFS MS het nakijken geeft in hoe het wel moet. Er zijn miljoenen devices voorzien van APFS die ook nog eens dynamisch omgezet zijn bij een upgrade wat vlot verliep. APFS moet wel betrouwbaar zijn, anders gaan al die IOS gebruikers klagen... ReFS uit consumenten versies halen is dom gezien dat ook allemaal 'testers' zijn en de betrouwbaarheid op termijn ten goede komt. Maar blijkbaar heeft MS niet ZO veel vertrouwen om het daar in te zetten. Of ReFS is helemaal niet en nooit bedoeld om NTFS te vervangen. Dat kan natuurlijk ook...
Toevoeging, voor bijvoorbeeld Exchange 2016 is het het aanbevolen filesystem, maar dien je wel een aantal features te disablen.
Juist, maar dat komt door hun recommended server architectuur (JBOD) en dan geld het alleen voor de database en log locatie.
https://blogs.technet.mic...6-preferred-architecture/
De Exchange installatie moet nog steeds op NTFS. Voor de geïnteresseerden:
https://practical365.com/...-exchange-server-volumes/
Klopt helemaal, is ook een (mogelijke) examenvraag voor 70-345.
Dat zijn allemaal leuke technische smoesjes, maar zoals je zelf later ook aanhaalt: het draait om geld. Wil je nu ReFS, dan betaal je maar meer aan MS en dan mag je het weer. Dat is waar het op neer komt, en geen enkel ander feitje zoals boot support maakt daar een verschil aan. Alle technische bezwaren gelden voor Windows 10 Pro Workstation nog steeds, maar daar kan het wel, wat er op duidt dat het dus eigenlijk totaal niet om technische bezwaren gaat maar om segmentatie en geld verdienen.

Bij Apple gaat dat anders, daar krijg je OS updates gratis en is een upgrade naar APFS ook gewoon voor iedereen met hardware van de laatste 5 jaar gratis te gebruiken.

Ook bij Red Hat Linux en de betaalde subscriptions met RHEL krijg je ook gewon alle filesystems. Dat geldt ook voor bijvoorbeeld Debian, Ubuntu, Fedora en Slackware.

Bij Oracle Linux is er dan wel e.e.a. alleen als betaalde addon te krijgen, maar dat was bij Oracle nooit anders. Hetzelfde geldt natuurlijk voor IBM, als je daar wat extra's wil mag je meteen je hele portemonnee inleveren, maar ook daar geldt weer: dat was altijd al zo. Features worden niet verwijderd en daarna als optionele betaalde upgrade neergezet.
Dus? Geld moet ergens vandaan komen, vooral je nu Windows bij een pakje boter krijgt.

Apple verkoopt de software ook, zit gewoon bij de productprijs in. Die updates zijn niet echt gratis. Je betaald daar gewoon vooraf voor.

Bij Windows was het ook nooit anders dat je voor bepaalde onderdelen een hogere/duurdere SKU nodig had. En het is ook altijd geweest dat bepaalde features heen en weer schuiven door de SKU's heen.

We hebben het ook alleen maar om ReFS volumes aanmaken. Gebruiken kan op elke Windows client nog gewoon. Technische smoesjes maken hier vrij weinig uit, Dit besluit is gemaakt om de SKU's wat meer van elkaar te onderscheiden, en zo -hoopt MS- net wat meer Enterprise licenties te verkopen.
Dus: het gaat hier niet om technische redenen maar om geld. Doen alsof het technisch is terwijl het gewoon geld is vind ik een beetje gek.
U was onder de indruk dat Microsoft een liefdadigheids instelling was?

Er zijn ook technische redenen waarom ReFS niet klaar is voor 'het publiek'. Maar dat staat los van het schuiven met features tussen de SKU's.

Windows moet nu eenmaal inkomsten genereren. Liever dat ze het grootste gedeelte van hun inkomen uit de zakelijke wereld halen doormiddel van producten en diensten verkopen. Dan andere praktijken.
Ja onbegrijpelijk. Zo blijven ze 2 file systemen houden, terwijl je eigenlijk zou verwachten dat NTFS uiteindelijk uitgefaseerd zou worden. Hoe oud is ntfs ook wel niet?
Ja onbegrijpelijk. Zo blijven ze 2 file systemen houden, terwijl je eigenlijk zou verwachten dat NTFS uiteindelijk uitgefaseerd zou worden. Hoe oud is ntfs ook wel niet?
NTFS is in juli 1993 geïntroduceerd met Windows NT 3.1. Maar de huidige NTFS is niet de NTFS van toen, de huidige versie is 3.1. Deze is geïntroduceerd met Windows XP, maar sindsdien zijn er wel nog een hoop features toegevoegd alleen is het versienummer nooit meer omhoog gegaan. Leeftijd wil niet zeggen dat een filesysteem slecht is geworden.

Twee filesystemen onderhouden valt nog mee. Kijk eens naar Linux uit hoeveel filesystemen je daar mag kiezen: etx2, ext3, ext4, xfs en nog anderen. Is dat slecht? Nee, het geeft je wel flexibiliteit afhankelijk van wat je wil gaan doen.
MS gebruikt FAT ook nog.

De huidige NTFS versie is net zo oud als Windows 10.

NTFS wordt bijna elke Windows release geupdate en verbeterd.
gebruiken is veel gezegd, enkel exFAT wordt nog actief gebruikt voor externe devices, voor al de andere FAT standaarden moet je al zoeken naar iemand die hem nog gebruikt, al is het nog wel ondersteund om volumes te formatteren in FAT(16) en FAT32 naast NTFS, UDF en ReFS (binnenkort dus niet meer).
Op kleine devices kan je nog gewoon FAT gebruiken, naast FAT33. Verder is er ondersteuning voor CDFS naast UDF.
Op kleine devices kan je nog gewoon FAT gebruiken, naast FAT33. Verder is er ondersteuning voor CDFS naast UDF.
Ik hoop dat je FAT32 bedoelt.
Gewoon FAT werkt ook nog. Ook wel bekend als partitie type 0x01 en FAT12. Alleen kan je het niet op alle devices gebruiken.
Gewoon FAT werkt ook nog. Ook wel bekend als partitie type 0x01 en FAT12. Alleen kan je het niet op alle devices gebruiken.
Ik doelde op de vermelding van FAT33.
Lol, klopt :) zie nu pas dat ik 33 schreef in plaats van 32.
USB-sticks komen nog steeds gewoon FAT32-geformatteerd uit de verpakking hoor. Niks exFAT. Probeer maar eens een bestand, dat groter is dan 4 GB, naar je nieuwe stick te kopiëren. Gaat je niet lukken.
De keuze om een Drive naar fat16 of fat32 te formatteren zit er nog in door al die knakkers die Windows xp zijn blijven gebruiken. Ondersteuning voor alle fat systemen, behalve exfat, zal komende jaren verdwijnen
Bijzonder vervelend is ook dat als je met de Media Creation Tool een boot USB-stick maakt voor Windows 10 dit niet in NTFS gedaan wordt maar ook nog met exFAT. Nu weet ik wel dat het een boot stick is maar toch. Als je daar grote bestanden bij wilt zetten, kan dat dus niet.
FAT is toch ook het FS voor je (U)EFI partitie? Op al m'n (U)EFI enabled Linux bakken in ieder geval wel.
Ja ik vind het echt achterlijk. Ik heb hier een Storage Space draaien met drie schijven op ReFS, omdat dit de toekomstige FS zou zijn. Tuurlijk is het nog in ontwikkeling, voordelen zijn er zeker wel. Dat NTFS oud is, is ook niet de reden maar technieken gaan vooruit dus het on the fly detecteren van schrijffouten is bijvoorbeeld een schitterende functie.

Ook al zit deduplicatie er nog niet in (oké, voor thuisgebruikers minder interessant, voor bedrijven wél) en kan je nog niet vanaf booten (kortom, nog in ontwikkeling), ik heb zelf nog geen problemen betreffende stabiliteit gezien.

Erg jammer, naar mijn mening speel je zo illegale windows-versies in de hand. Want zoals hier in een reactie ergens al staat, als ze dus de Pro for Workstations in maandabo gaan maken of erg duur gaan maken, dan wordt het erg duur. Te duur voor mij tenminste. Maar misschien ben ik te voorbarig, eerst afwachten wat daarin de prijs wordt.
Te duur, kom nou, wat kost een pro ws licentie nou, of een ee versie. Al is het 250 euro, afgeschreven over 5 jaar is dat 50 euro per jaar. Er zijn mensen die een game van 16 uur spelen voor 69 kopen. En een OS gebruik je iedere dag.
Te duur, kom nou, wat kost een pro ws licentie nou
Voor sommige van ons is 250 euro een flinke bak. En voor weer anderen is het ook gewoonweg niet nodig, om wat voor reden dan ook (geen noodzaak voor X en Y features, tevreden met een andere OS, noem maar op)
Mensen die geen 250 euro voor die licentie hebben zitten waarschijnlijk niet in een situatie waar ze echt iets aan ReFS hebben.

Als 250 euro voor iemand een flinke bak geld is dan heeft die persoon naar alle waarschijnlijkheid sowieso wel andere prioriteiten dan pc gerelateerd spul.
Ik kan het prima betalen, maar ik vind 250 euro voor een Windows licentie veel en veel te veel. Dat vind ik trouwens van Red Hat ook, 300 dollar voor een RHEL Workstation licentie. Daarintegen draai ik al jaren met veel plezier Fedora, CentOS of Ubuntu, dus misschien is mijn mening ietwat gekleurd (alhoewel ik met Windows en Linux werk, dus met licenties regelmatig in aanraking kom)
Windows 10 is nog steeds gratis. Als je maar een valide Windows 8/8.1 of 7 key hebt. Windows installeren met zo een key en activeren gaat als een trein.
Dan is het dus niet gratis, aangezien je een key nodig hebt waar je voor moet betalen. Ook al zat Windows bij je PC, dan heb je er alsnog voor betaald. De fabrikant rekent de kosten voor de licenties gewoon door aan haar klanten.
Ik heb het over abonnementsdienst (of hoe je het wilt noemen). In geval van 250 euro valt het nog mee, ik wil zelfs nog wel 250 per jaar betalen aangezien ik het veel gebruik. Maar maak er nu eens 1000 euro van per jaar, dat is al een heel ander bedrag. Dus jij noemt nu 250 euro, en zegt tegen mij dat dat niet duur is, maar je weet zelf ook nog niet hoeveel het gaat kosten. Daarom ook mijn laatste zin in mijn comment.

[Reactie gewijzigd door Ruubster op 23 augustus 2017 11:33]

Ja ik vind het echt achterlijk. Ik heb hier een Storage Space draaien met drie schijven op ReFS, omdat dit de toekomstige FS zou zijn.
Hier idem dito. Weliswaar on Windows 8.1 pro, maar toch..
Geen problemen mee en al drie jaar in gebruik zonder morren.
Je kunt het wel gebruiken alleen niet meer aanmaken, dat is een belangrijk verschil, met een third party tool kan je het mogelijk alsnog wel aanmaken.
Mijn reactie was meer op het statement van t.net dat ReFS een opvolger voor NTFS is. Dat lijkt me dus niet, in ieder geval voorlopig niet, anders zouden ze in plaats van ReFS uit edities slopen het wel in méér edities introduceren.
Op termijn (aka. 2030) zullen we wel allemaal onze hdd ReFS formatteren. Nu is het gewoon een beetje "damage control" aangezien nog niet alles geimplementeerd is en dus meer miserie veroorzaakt als jan met de pet dit gaat doen.
Omdat de meeste ReFS features naar NTFs is overgezet en een aantal is omgebouwd tot Windows service, zoals de indexing service.

En zoals Dycell aangeeft, refs is ook nog niet echt klaar om als volledig filesystem gebruikt te worden.
Waarom kan Windows niet overweg met andere fs, zoals die ext2/3/4, btrfs, hsf(+), etc.
Ze willen meer openheid maar tegelijkertijd zie ik dat niet echt gebeuren.
Mede omdat veel van die filesystems streng hoofdlettergevoelig zijn en Windows dat absoluut niet is. Windows begrijpt niet dat /root /Root /ROOT drie verschilende dirs mogen zijn.
Dat is niet waar. Technisch ondersteunen zowel NTFS als Windows hoofdlettergevoeligheid, het is alleen standaard niet ingeschakeld (en veel applicaties gaan ervan uit dat de omgeving niet hoofdlettergevoelig is.

Overigens een leuk artikel om te lezen: https://blogs.msdn.micros.../wsl-file-system-support/
Hierin wordt uitgelegd hoe Microsoft de file system support aan WSL (Bash on Ubuntu on Windows) heeft geïmplementeerd.
Lijkt me dat daat eigenlijk mooi onder een filesystem-abstractielaagje zou moeten zitten, maar gezien hoe Windows nog zo hard vast zit aan ook wel wat andere problematische DOS-principes kan ik er heel goed inkomen dat dat inderdaad best wel een groot probleem is.
Microsoft heeft met Windows 7 bijvoorbeeld geprobeerd om de 260 karakter max in een padnaam eindelijk naar de verleden tijd te brengen. Dat zou destijds veel te veel software en drivers slopen. Omdat er een heleboel in Windows aangepast diende te worden. Wat jaren aan backwards compatibiliteit weg zou vagen.

Sinds een tijdje is het optioneel in Windows 10.

Gewoon alleen al dit stukje DOS legacy wegwerken uit Windows heeft 3 (5+) generaties Windows gekost voor dat werk eindelijk "af" was.

Met Windows 8 en 10 is er een hele bult legacy spul uit de jaren 90 of zelfs begin van het millenium gedropt.

1 ding is enorm belangrijk voor MS, de voornamelijkste reden dat ze nog een dominante speler zijn in een paar markten of hoeken van markten... Backwards compatibility. Dat je 30+ jaar aan legacy spul nog op moderne systemen kan draaien zonder al te veel gedoe. Ze zijn er echt uiterst voorzichtig mee willen ze wat aanraken in Windows. 9/10 keer lukt het MS om her en der wat te droppen of volledig opnieuw op te bouwen inclusief compatibility laag, zonder dat iemand het ooit doorheeft.

Die ander 1e keer, valt het halve internet er over heen. Wat deed men moeilijk dat hun HP desktjet 1998 editie niet meer werkte op Windows 10. Heeft MS eindelijk die antieke printer service vervangen met een modern stukje technologie... Wordt daar weer moeilijk over gedaan. Net als dat het muis model vervangen is met Windows 8, terwijl daar wel een "backwards compatibility laagje" bij zat in de vorm van een disable knopje. Ook daar deden genoeg mensen moeilijk over "hoe durft MS" blabla.

Voor die problematische DOS principes mag je bij developers aankloppen. Die hebben al een paar decenia stug compleet en totaal schijt aan guidelines en voorschiften en hebben al moeite met het snappen van het woordje DEPRECATED.

Als men nu eens niet Microsoft zou aanvallen als er een programma, game of driver de boel om zeep helpt. Maar de developers... Was het niet zo'n probleem geweest. Maar 90%+ van die anti-MS haat is echt totaal onterecht. Het overgrote deel aan crashes is echt gewoon te wijten aan brakke software/drivers, en niet Windows. Die overige 10% zijn eigenlijk allemaal privacy gerelateerd, welke niet zo zeer onterecht zijn omdat het persoonlijk is wie je wel of niet met je data vertrouwd.

Verder is het wel in ons voordeel geweest, dat Windows vandaag de dag zo ontzettend stabiel is komt hier deels voor. Windows is echt ontzettend goed geworden in het opvangen van brakke hardware en software, en Windows gaat op dit vlak, ver...ver voorbij Linux, de koning van de stabiele OSen.

De meeste software/games vandaag de dag is +/- net zo brak geschreven als 10-20 jaar geleden. Aan de driver kant gaat het een stuk beter, maar hier kan Microsoft makkelijker hun wil opleggen.
Voor die problematische DOS principes mag je bij developers aankloppen. Die hebben al een paar decenia stug compleet en totaal schijt aan guidelines en voorschiften en hebben al moeite met het snappen van het woordje DEPRECATED.
Over zwart-wit denken gesproken.. Vaak wil een developer (of een team) wel, maar worden ze van hogerop teruggefloten. Het gaat in zulke situaties eerder om geld dan om technische zaken. De manager heeft zoiets van "als X werkt, en Y ook, waarom dan over van X naar Y? Kost geld..".
Ik doelde ook niet echt alleen de programeurs e.d. Maar de hele partij die de meuk ontwikkeld.
Ehm... je gaat me niet serieus willen nemen, wat niet mijn probleem is, maar ik moest toch even lachen toen je begon over hoe Windows tegenwoordig zoveel stabielers is dan in het verleden. Klopt echt helemaal niks van in mijn ervaring.

Verder ben ik het wel met je eens over developers die alle guidelines aan hun laars lappen, maar dat telt voor Linux etc ook. Meeste problemen worden gewoon veroorzaakt door developers die zoiets hebben van "ik kan het fatsoeinlijk doen... of ik kan even snel een shortcut nemen door een API te gebruiken voor iets waar die niet voor dient. Zal vast wel blijven werken." En iedereen die programmeert is zich daar waarschijnlijk soms wel schuldig aan. Maar wanneer dat bij het maken van drivers gebeurt dan zit je inderdaad in de problemen.

Overigens ook interessant om te weten dat ze die character limit er eindelijk uit hebben weten te slopen. Was ik niet van op de hoogte. Nu nog van die achterlijke C:, D:, E:, ... afkomen ooit ;-) Dat gaat volgens mij gewoon nooit gebeuren, maar heeft af en toe ook wel eens wat problemen. Altijd grappig als na een WIndows-installatie je system partition plots E: heet (gebeurt soms, hoewel minder dan in het XP-tijdperk) en de helft van de programma's op mysterieuze wijze niet meer werken :9 Again, admittedly veelal de fout van developers die gewoon C: hardcoden terwijl er een environment variable voor is die ze zo kunnen uitlezen, maar dat zijn dan weer problemen die je met Linux en de BSD-broertjes (o.a. MacOS) niet hebt door een (imo) op dat gebied op zijn minst superieure architectuur.
N = 1

Eens wat channel 9 videos kijken en/of msdn blogs lezen over hoe Windows een boel fouten, errors en problemen van de hardware en software opvangt.

Mijn eigen ervaringen ook, Windows wat gewoon blijft draaien als er een ram, gpu of cpu uitklapt. Drivers die dusdanig brak zijn dat Windows met moeite de boel overeind weet te houden, af en toe met afmelden als gevolg door de user af te schieten.

Op Linux gebeurd het ook, maar verhoudingsgewijs minder. Een groot deel van de linux developers heeft een band met het OS en/of de community.

Met distros als Debian die relatief erg streng zijn met wat ze wel of niet goedkeuren in hun stable builds, die het voorbeeld neerzetten.
klopt, ik zeg soms half lachend, half serieus dat windows een flop/top release heeft.
Maar veel van die flops worden veroorzaakt door het laten vallen van dergelijke compatibiliteiten en nog meer dat de 3rden niet mee willen of kunnen met hun drivers en applicaties.
Vista was eigenlijk niet zo veel slechter dan XP, maar daar weer acceptatie en driver ondersteuning liep ver achter. XP had daar geen last meer van en werd dus beter onthaald. Maar er zijn nu nog mensen die met evenveel gemak en stabiliteit vista gebruiken als XP. (ook al stappen ze veel beter over op een ondersteund os) verdere vergelijkbare situaties voor :het invoeren van UAC, het afschermen van program files en windows directory, het laten vallen van de ini file. Zijn allemaal zaken waar de eerste versie van een nieuwe generatie op afgerekend werd, terwijl de opvolger daar geen last meer van heeft.
Ze zitten er hard aan vast omdat ontzettend veel legacy code hier sterk van afhankelijk is. Ook moderne scripts worden nog altijd klakkeloos C:\HoofdLeterONGEVOELIGgeschreven\
Dat is geen faire vergelijking. NTFS ondersteunt padnamen tot 32768 Unicode karakters, en de documentatie (al vóór Windows XP) wijst hierop. Het is dus enigzins redelijk om programma's met een 260 karakter limiet "legacy" te noemen. Maar hoofdletter ongevoeligheid is een gedocumenteerd feature, en nooit ter discussie geweest. Dat is dus geen "legacy", dat is hoe Windows werkt.
Gaat er meer om dat architecture wise dat onder een filesystem-abstractielaag hoort te zitten in plaats van dat er overal tot in de core van het systeem vanuitgegaan wordt dat het voor elk filesystem altijd zo is. Als er overal in het hele systeem altijd vanuitgegaan wordt dat paden niet hoofdlettergevoelig zijn is dat niet bepaald future-proof.
En omgekeerd is het niet handig dat er van uit gegaan wordt dat filenames wél hoofdletter geveoelig zijn.

Overigens denk ik dat je een verkeerde aanname maakt,. Windows "gaat er niet van uit" dat paden hoofdletter-ongevoelig zijn. Windows zorgt daarvoor. Tenminste, het Win32 subsysteem doet dat. WSL (Linux onder W10) doet het niet, en NTFS zelf is hoofdletter-gevoelig.
Dat is het punt net. Je zou er nergen vanuit mogen gaan en het zou dus volledig afhankelijk moeten zijn van de filesystem-driver ;-)

NTFS is niet hoofdlettergevoelig trouwens. Probeer zelfs in Linux maar eens op een NTFS-partitie files genaamd hallo, HALLO en HaLlO aan te maken.
NTFS is hoofdletter-gevoelig. Wat jij ziet hangt af van jouw mount opties. De mount.lowntfs-3g tool heeft een "ignore-case" optie.
Even opgezocht, en je lijkt gelijk te hebben. Weer wat bijgeleerd. Dus het probleem zit hem wel effectief in Windows zelf. Maar als NTFS in principe al case sensitive is zou het dus wel mogelijk zijn om ext4 support te hebben in Windows, gezien dezelfde regels dan van toepassing zouden kunnen zijn 😮

Ben nu wel benieuwd wat er zou gebeuren als ik dus files aanmaak op een NTFS filesystem met dezelfde naam maar verschillend in casing. Zou die net als wanneer je per ongeluk een file op een NTFS-partitie aanmaakt die : bevat flippen als je de file probeert te openen en bij de volgende schijf controle de hele partitie nuken? 😂
Oh, ext4 support is geen enkel technisch probleem. 't Is primair een organisatorisch probleem. je hebt de IFS (Installable File System) SDK nodig, en aangezien FS drivers core system components zijn moet het ondertekend worden.

Ik heb het in een vorige baan serieus overwogen, maar het was handiger om een DLL te bakken van de ext3 code.
MrKuromili in 'nieuws: Microsoft haalt mogelijkheid om ReFS-volumes te maken ... ;) Daar ging de hele thread in principe net om, dus daarom.

[Reactie gewijzigd door RobinJ1995 op 24 augustus 2017 12:25]

da's dan de schuld van een slordige programmeur. Velen schrijven proper hun variabelen met HoofdLetters en hun commando's in CAPS zoals het hoort
Aangezien commando's gewoon executables zijn zouden die dus niet werken als Windows hoofdlettergevoelig zou zijn.
zoals het hoort is ook maar een menig en geen feit.
het schrijven met of zonder hoofdletter heeft imho niets te maken met "proper".
Het maakt het handiger leesbaar in een zwart wit editor en als je die specifieke conventies gewoon bent.

sommige conventies en schrijfstijlen in programmeren vind ik zelfs alles behalve proper en slecht leesbaar.
het gebruik van de haakjes bvb. |:(

Nuja elk zijn smaak en gewoonte, daar valt niet over te discussiëren.

het hoofdletter ongevoelig zijn vind ik soms zelfs en voordeel.
je kan dat zelf schrijven zoals je wil in je scripts, windows gebruikt toch enkel 1 vorm.
je mag dan wel niet verschillende betekenis geven aan hetzelfde woord of begrip.
en dat vind ik persoonlijk trouwens "slordig". Root ROOT of root zou maar op 1 ding mogen slaan.
nl de root van je os. Als je dat 3 verschillende betekenissen geeft naar gelang van de hoofdletters zorg je enkel voor verwarring, en dat kan je beter vermijden door een betere naam te geven.

Door het een betere naam te geven, vermijd je verwarring bij mensen die niets van jouw conventies kennen of zelfs als ze andere en misschien tegenstrijdige conventies hebben.
we zijn de tijd al lang gepasseerd dat we moeten kijken op de lengte van namen.
Nee ik prefereer liever lange duidelijke namen dan korte cryptische omschrijvingen.
het gebruik van hoofdletters maakt het voor mij wel gemakkelijker om de dingen te lezen.
omdat commando's en variabelen best geen spaties vervangen is het wel zo handig om die te vervangen met een hoofdletter bij het volgend woord.
GetScreenInput leest handiger dan getscreeninput.
Dit is helemaal niet de reden waarom NTFS dit doet, hfs+ op OSX is per default ook case insensitive. Dit is een UX beslissing en helpt doorsnee gebruiker makkelijker hun files vinden, als ze per ongeluk capslock aan hebben staan en zijn aan het typen om een dir te vinden.

Het zou misschien beter zijn als NTFS en ReFS dit in een optie onderbrachten, maar dan ga je teveel foutmeldingen zien in windows. Omdat te veel code voor windows nu eenmaal case insenstive is geschreven op dit moment.
Tja, en ik vind het ook niet vreemd dat Windows dat niet 'begrijpt', vind het namelijk van den zotte dat zoiets mogelijk is. zelfde als in C dat een x een andere variabele is dan X 8)7
Dat is toch in elke behoorlijke zichzelf respecterende taal? Heck, zelfs PHP heeft dat, waar $x wat anders is dan $X (tenzij je $X = $x = 5 doet, dan zijn ze beide 5)
Sorry hoor, maar een zichzelf respecterende taal zou juist NOOIT! zoiets toestaan, alleen al vanwege typefouten. Een programmeertaal (en bestandssysteem) zou nooit casesensitive mogen zijn, dat kan voor veel te veel problemen zorgen (en dat doet het dus ook).
Een programmeertaal (en bestandssysteem) zou nooit casesensitive mogen zijn, dat kan voor veel te veel problemen zorgen (en dat doet het dus ook).
Niet met competente programmeurs / beheerders. Ik draai een case-sensitive FS (XFS en ext4), en heb er tot nu toe nog nooit last van gehad ;-)
heeft niets met competentie te maken, het gebruik van dezelfde uitgesproken naam maakt het enkel verwarrender voor teamwerk en voor mensen die na jou de code moeten onderhouden.
Source code leest gewoon weg extra moeilijk als je de betekenis van variabelen en commando's laat afhangen van hun schrijfwijze.
heb ook zo'n collega gehad die alles zo cryptisch mogelijk schreef en dan kreeg je code van Gs_v
schrijf gewoon GetScreenVariable dat leest 20 keer handiger.
Waarom zou je ? Waarom c:\december of c:\DEcember ... Dat heeft toch totaal geen nut, dezelfde naam geving maar de ene met een hoofdletter en de andere niet. Echt waar dat heeft echt niets met competentie te maken, ik snap dan ook niet hoe je die mensen compentent kunt noemen, het heeft echt geen nut.
Ik denk dat het maar net is wat je gewend bent dan? Ik zelf zie absoluut geen probleem met een case-sensitive FS. Houd het, in mijn geval, overal consistent qua naamgevingen.
Ja en dan belt er iemand die een bestand niet kan vinden... Stond in december of December of DeCember, enz. folder. Kortom leuk dat het kan, verder niet echt efficiënt
En daar heb je dan je fileverkenner voor, waar een zoekfunctie inzit. Al jaren en jaren en jaren. Bovendien is het niet de schuld van het FS als je een gebruiker hebt die zo chaotisch is als een olifant in een porseleinkast.

Een stuk software is zo efficiënt als de gebruiker erachter. Als je weet dat je vaak dingen kwijt raakt is het een kwestie van jezelf aan één naamschema houden. Ik zie dus niet in hoe dit aan het FS ligt.
Niet echt. Voor je grafische zoekmogelijkheden had had je al locate en find ;-)
Dat is toch in elke behoorlijke zichzelf respecterende taal?
In normale talen betekent een woord hetzelfde ongeacht of het met hoofletters is geschreven. Alleen in bepaalde software gerelateerde talen kan de aanwezigheid van 1 of meerdere hoofdletters ertoe leiden dat een woord totaal verschillende ongerelateerde elementen kunnen worden.
"helping your Uncle Jack off a horse" en "helping your uncle jack off a horse." zijn toch twee heel veschillende betekenissen.
Dat komt niet alleen door de hoofdletter maar ook door de context. als ik de context verander betekent het wel hetzelfde:
My uncle Jack is an old man of
My uncle jack is an old man
Nu houd je je niet aan de afspraken der taal. Namen schrijven we in het Engels met een hoofdletter.

Daarentegen waren beide zinnen die ik gaf taalkundig juist.

Om de vergelijking compleet te maken, "My uncle jack is an old man" is geen geldig Engels, en geeft een syntaxfout.
Dat klopt maar dat komt omdat in talen als Nederlands en Engels afspraken gemaakt zijn over hoofdlettergebruik die niet betrekking hebben op betekenis maar op functionaliteit/herkenbaarheid.
bijvoorbeeld een hoofdletter om het begin van een zin te markeren of de naam van een persoon of land.
... (tenzij je $X = $x = 5 doet, dan zijn ze beide 5)
Maar het zijn nog steeds verschillende objecten. Als je 1 van de twee aanpast verandert de ander niet mee.
Hoezo? x is een andere [char] dan X.
In ASCII is x nu eenmaal iets anders dan X in bits uitgedrukt. (of UTF, ISO of unicode etc)

In C zijn variabelen (vergelijkbaar met placeholders voor) geheugen adressen. Dat x en X niet hetzelfde zijn, vind ik niet zo raar...zijn immers twee verschillende bit(rij)waarden.
Dat is natuurlijk een onzin-argument. "int X" is inderdaad een naam voor een locatie in RAM, net zoals "C:\X.txt" naar een locatie op disk verwijst. Maar net zoals "c:\x.txt" naar dezelfde locatie op disk verwijst had je kunnen afspreken dat "int x" naar hetzelfde geheugen verwijst.

De achterliggende reden is dat C net zoals Unix uit de AT&T stal komt, en ontworpen is voor techneuten door techneuten. Beiden zijn case-sensitive. Dat is het makkelijkste: een string compare is een byte compare.
Geen onzin argument.
Dat was toen de gangbare gedachte.

Dat we nu anders denken, doet niets af aan de prestatie in het verleden.
[case-sensitivity] was toen de gangbare gedachte.
Onzin, zoals ik al zei. En ik kan dat onderbouwen. "Rationale for the ANSI C Programming Language", pagina 20. De bestaande praktijk wordt daar in detail beschreven, als "6 characters, case insensitive".
Wat je beschrijft ("6 characters, case insensitive"), was toen juist niet algemene praktijk voor (interne) variabelen in de jaren 70. Dat behoort zelfs nu nog niet tot de bestaande praktijk!

Op dezelfde pagina maar iets ervoor:
"The Committee has decided to label as obsolescent the practice of providing
different identifier significance for internal and external identifers, thereby signalling
its intent that some future version of the C Standard require 31-character case-
sensitive external name significance, and thereby encouraging new implementations
to support such significance."
Wat jij nou probeert wijs te maken, is dat de ANSI commissie voor ALLE identifiers (variabelen, zo je wilt) ongevoeligheid beoogde in C. Die ongevoeligheid is juist NIET afgedwongen met het oog op de toekomst EN de toen vertegenwoordigde programmeerstijlen.

Veel zaken worden aan de programmeur en compiler overgelaten (namen, typen, geheugenmanagement etc.), zoals ook uit de latere revisies blijkt.

Overigens zitten er tussen de eerste publicatie van C, C89/90 en C11 behoorlijk wat jaren en ELKE C programmeur (niet-beginnend iig) weet nu wel dat C (en de meeste afgeleiden) gevoelig is voor hoofdlettergebruik in variabelen.
Strikt genomen valt dit onder ISO WG14 (C), en was ik lid van WG21 (C++), maar dit specifieke stukje ging over linkers. WG14 en WG21 werken samen om de talen link-compatible te houden, dus dit is bekende kost.

Deze rationale gaat niet over "programmeerstijlen". Dit gaat over linkers. Dat is waarom external identifiers genoemd worden; die worden namelijk gelinkt. Het stukje wat jij quote stelt dat voro internal identifiers dezelfde regels zouden moeten gelden, ook al worden die niet gelinkt.

En de obervatie van ANSI was dus dat bestaande 1970 linkers een limiet van 6 karakters hadden, en case insensitive waren.
Namen van externe linkers hebben helemaal geen limiet van 6 karakters. De programmeur is vrij om binnen 31 karakters met 6 unieke beginletters combinatie namen te vormen. Daarbij is ee nog steeds ruimte om nog langere namen te gebruiken.

Er wordt ook nergens gesteld dat interne en externe variabelen gelijk behandeld moeten worden.

Dit als reactie op de observatie opmerking. Op dat laatste is overigens ook vandaag de dag geen uniforme mening onder professionals en (hobby)programmeurs. Te veel verschillende mensen vinden afspraken prima, mits die niet beperkend werken.

Dat laatste zal nooit veranderen, omdat C in de basis al heel veel vrijheid en flexibiliteit toelaat en realiseert. (Meer dan vele andere talen).

[Reactie gewijzigd door ProjWorld op 24 augustus 2017 13:16]

Klopt dat het geheugenadressen representeren, maar het is de designer van de taal die heeft besloten om in de mensleesbare variant dit zo te beslissen. Heel veel fouten in software komt door dit soort onzin, vooral bij de talen waar je niet eerst alles expliciet moet definieren.
Dat het technisch gezien een ander character is maakt niet uit, het character representeert voor degene die het moet lezen nog steeds de letter x (of die nu hoofdletter of kleine letter is).
En in code maakt het niet uit of jij het document opgeslagen hebt in UTF of ISO8859, de compiler zal deze TEKST omzetten naar voor de computer leesbare code. Je schrijft code in een voor mens leesbare taal en dus gaat het verhaaltje niet op dat x en X technisch gezien een ander character is in een characterset, waarom zou je anders in een hogere taal gaan schrijven. De hogere programmeertaal is bedoeld om het makkelijker leesbaar/begrijpbaar te maken voor de gebruiker, want voor de computer zelf maakt het geen drol uit, die krijgt toch voor de meeste onbegrijpbare bitjes voor zijn snuffer.
Staan Java of andere hogere talen niet verder van de machinetaal af dan C?

Mijn punt is dat de kritiek op de implementatie van C onterecht is, omdat dat toen de gangbare gedachte was. Met de kennis van nu kun je zowat alle design beslissingen in de IT bekritiseren.

(Net zoals IPv4...hadden ze toen al moeten voorzien dat dat niet genoeg was. Hoe stom is het dan dat IPv6 ooit ook weer de limiet bereikt?)
Je zou je eens wat beter in de geschiedenis van de IT moeten verdiepen, het aantal foute aannames wat je maakt is schokkend.

IPv4 definieert 4 miljard IP adressen met 4 bytes elk. Die collectie van adressen is 16 GB groot, in een tijd dat 4 MB RAM veel was. Dat had serieuze consequenties voor routers van toen. Een nog groter aantal IP adressen had ervoor gezorgd dat IP niet gewonnen had als standaard. Dan hadden we nu miscshien X.25 of zo gehad. IPv6 werd alleen mogelijk door twee decennia van de Wet van Moore.

En wat betreft Java versus C : we hebben het hier over de front-end. Die maakt een Abstract Syntax Tree van de source code. Dat deel is in C en Java niet fundamenteel anders; het verschil zit 'm in de back-end die de AST omzet in iets binairs.
Overdrijven is ook een kunst. Ik tel max 4 zogenaamde aannames...als je dat al schokkend vindt...
Ik heb op je eerdere reactie (elders) al gereageerd.

Ik weet niet hoe je werkt of wat je ervaring in C is, maar het begint altijd met de persoon zelf. TU en chief technology officer ten spijt: je bent volgens mij geen C programmeur op (bijna) bare metal niveau. Als je dan toch AST benoemt, behoor je ook te weten dat de compiler/IDE hoofdletterongevoeligheid kan afdwingen...

Voor als het nog niet duidelijk was: Ik benut actief de hoofdlettergevoeligheid om mijn code leesbaar te houden, te organiseren en externe bronnen te linken. Mag ik nu niet meer zeggen dat ik de kritiek op hoofdlettergevoeligheid onterecht vind? Is elk argument dan onzin? Kom dan eens met de concrete, feitelijke fout en wijs mij op het tegendeel...want dat laat je achterwege.
Dat vind ik persoonlijk enkel een pluspunt, eigenlijk.
Als programmeur heb ik de inconsistentie van mensen altijd vreselijk gevonden. De één gebruikt PascalCase, de andere camelCase, de ander schrijft specifieke folders in CAPS, de ander in kleine letters, de ander enkel de eerste letter met als hoofdletter...

Zelf houd ik de foldernamen kort (één woord) en lowercase, maar dit doet lang niet iedereen. Het feit dat windows niet hoofdletter gevoelig is, veroorzaakt dat veel mensen geen dubbele mapnamen e.d. aan gaan maken en dat is erg prettig.

Aan de andere kant, switch je applicatie naar linux en alles dondert uit elkaar omdat een programmeur dus inderdaad z'n cases door elkaar heeft gehaald.

Dus je hebt een punt, maar ik vind PERSOONLIJK, dat windows zijn "onverschilligheid" tegenover hoofdletters in folderstructuren geweldig is. Tenslotte is het gewoon dom om verschillende folders met verschillende doelen dezelfde naam te geven met als enige verschil hoofdletters.
Omdat je voor Windows een speciale SDK moe(s)t hebben om een file system driver te maken. En zonder die SDK kan je dus geen file system toevoegen aan Windows.
Er zijn ext drivers voor Windows. Het is niet MS hun filesystem, dus waarom zouden ze het mee moeten leveren.

En toevoeging op MMaster23: Windows maakt wel degelijk een onderscheid tussen hoofd en kleine letters. Kiest hier bij NTFS en FAT bijvoorbeeld voor om het te negeren.
Kijk eens naar de software van Paragon, dat is echt geniaal spul.
Het is geheel open om zelf je eigen FS drivers/modules te schrijven. Voor ext2/ext3 bestaan ze gewoon alleen zijn de meeste uitvoeringen niet gratis. Microsoft houdt niemand tegen om dit te doen. Ook kan Windows zonder problemen overweg met andere filesystems die verschil malen tussen hoofdletters en normale letters, geen enkel probleem zolang applicaties maar geen ToUpper/ToLower wrappers rond de i/o call's maken.
Het kan wel, er zit zelfs al heel lang (ben even kwijt of het sinds XP is of zelfs nog eerder) een mogelijkheid om je eigen filesystemdriver in windows te hangen, maar het is kennelijk wel een ondergeschoven kindje.
Ik lees een hoop kritiek, maar zijn er hier echt mensen die ReFS nu gebruiken en waarom dan? Want volgens mij is dat alleen nuttig voor een specifieke doelgroep. En als je het al gebruikt, kan je het sowieso blijven gebruiken. Of als je denkt dat je het wilt gaan gebruiken, schakel dan nu over dan blijf je dat hebben na de update.
Hier, ik heb het gebruikt als tegenhanger voor ZFS (nas4free) op voorhand goed getest,stress test schijven verwijderen terug stoppen enz. ging tijdens het testen prima. maar toen ik er 12 TB opzetten stortte het ReFs na een half jaar gebruik in. (bleek een crc error veroorzaakt door en sata kabel) I kde kabel vervangen en mijn disk proberen terug te zetten. Had beter niets kunnen doen want het systeem werkte nog en daarna nooit meer.
Op diverse fora zelfde geluiden gehoord. Dus mij zie je, voorlopig niet meer op ReFs terug naar NTFS was het makkelijkst maar het gaat weer ZFS worden. Zeer goede ervaringen mee.

Had eigenlijk mijn zinnen gezet op BTRF, omdat het beter is te integreren in kernels en duidelijk veel moderener is. Maar dat is duidelijk ook nog niet uitgekristalliseerd.
BTRFS is ook nog niet 100% stabiel, ds daar zou ik zéér mee oppassen. ZFS is tegenwoordig toch gewoon te doen in Linux als kernel module?
In linux kan ZFS toegevoegd worden maar voor zover ik weet mag het niet toegevoegd worden. ivm rechten van sun/oracle. Zal vast wel kunnen en er zullen vast wel hier en daar wat distributies zijn, of zelf compileren?

Ik kijk met een scheef oog naar de implementaties van xpenologie die op basis van Synology, die bijna wekelijk updates uitbrengen. Alleen is er nog geen 64 bit van xpenologie wel een loader voor de 6 en up versies, maar dat durf ik niet aan

Ik ben zeer te spreken over de ZFS implementatie van nas4free. niet teveel toeters en bellen en doet wat het moet doen
Het mag tijdens installatie niet meegeleverd worden, niemand die iets zegt over een post-install kernel module, zie ook http://zfsonlinux.org/
Zal iets te maken hebben met het eigendom of licenties die nu van Oracle zijn. Wordt nog wel ontwikkeld maar wie dat nu doet en onder welke voor waarden geen idee. Net als M0nowall die in Nas4free zit. geen ontwikkeling meer,http://m0n0.ch/wall/index.php Is nu opensense. Alert blijven dus

Ik zie ze graag tegemoet. Maar ik zie de ontwikkeling van BTRFS op het moment veel sneller gaan en ZFS een beetje verdringen. Zou ik op het moment jammer vinden omdat BTFS naar mijn idee nog lang niet zo stabiel is in vergelijk met ZFS.
Komt misschien ook omdat ZFS al veel ouder is en stabieler? BTRFS krijgt nu pas features die al jaren in ZFS, XFS en andere FS'en zitten (en een paar die daar niet inzitten). Het zijn nu de tienerjaren van het FS, met groeispurten en puberaal gedrag (als in: eet je data).

ZFS blijft gestaag groeien, maar qua features is het 'klaar', want het support zo'n beetje alles onder de zon al wat nodig en/of nuttig is voor een FS.
Nah, het is gewoon weer klagen om het klagen :)
Ik lees een hoop kritiek, maar zijn er hier echt mensen die ReFS nu gebruiken en waarom dan? Want volgens mij is dat alleen nuttig voor een specifieke doelgroep.
Het is nuttig voor sommigen zoals er ook mensen zijn die methodes als FreeBSD en zo gebruiken.
Vermoed ik. Storage Spaces is zelfredzaam en uitbreidbaar met (hard)disks van verschillende formaten.

Sorry, Engels :
Storage Spaces is a storage virtualization technology which succeeds Logical Disk Manager and allows the organization of physical disks into logical volumes similar to Logical Volume Manager (Linux), RAID1 or RAID5, but at a higher abstraction level.

A storage space behaves like a physical disk to the user, with thin provisioning of available disk space. The spaces are organized within a storage pool, i.e. a collection of physical disks, that can span multiple disks of different sizes, performance or technology (USB, SATA, SAS). The process of adding new disks or replacing failed or older disks is fully automatic, but can be controlled with PowerShell commands. The same storage pool can host multiple storage spaces. Storage Spaces have built-in resiliency from disk failures, which is achieved by either disk mirroring or striping with parity across the physical disks. Each storage pool on the ReFS filesystem is limited to 4 PB (4096 TB), but there are no limits on the total number of storage pools or the number of storage spaces within a pool.

[Reactie gewijzigd door stresstak op 22 augustus 2017 22:27]

Ik was naar ReFS overgeschakeld vanwege de officiële ondersteuning van padnamen langer dan 255 tekens. (Erg handig als je muziek ript, en je hebt een stapel klassieke muziek die je ook op de HDD wilt kunnen vinden, zonder gebruik van een programma dat de metadata in de bestanden leest.)

Daarnaast dacht ik erover om een mirrored storage space met ReFS op te zetten op mijn desktop, om te voorkomen dat ik al mijn data terug moet kopiëren als een HDD kapot gaat, en omdat het lekker makeklijk is om even een schijf toe te voegen als je meer ruimte nodig hebt, zonder daadwerkelijk een schijf erbij te krijgen in je Verkenner. De reden dat ik ReFS wilde gebruiken is omdat het metadata- en file checksums ondersteunt, en als een bestand corrupt wordt op één schijf, het automatisch van de andere hersteld kan worden. NTFS kan dat niet.

Het enige nadeel van ReFS op een dataschijf is dat de overhead veel groter is dan die van NTFS; 10GB op een 2TB HDD, terwijl die van NTFS 378 MB is. (En van ReFS kan je niet booten, omdat het een aantal features niet heeft, die Windows zelf nodig heeft, zoals hard links.)

PS: Ik heb mijn backupschijf teruggezet op NTFS; als een bestandssysteem niet officieel ondersteund wordt (lezen én maken), dan gebruik ik het niet. De schijf in mijn laptop heb ik nog niet gedaan. Het verschil tussen de twee schijven was enorm: de interne ReFS schijf had 30GB meer ruimte in gebruik dan de NTFS backupschijf, met dezelfde bestanden. ReFS heeft dus een enorme overhead.

[Reactie gewijzigd door Katsunami op 23 augustus 2017 04:05]

Windows 10 Pro is langzamerhand gewoon de Home versie geworden waarmee het toevallig mogelijk is om op een AD aan te melden. Bij elke update wordt steeds meer Pro functionaliteit gestript en bloatware toegevoegd om bedrijven te dwingen naar een Enterprise licentie. Beetje treurig beleid van Microsoft.
Wat mis je dan zoal nog meer dat eerst wel beschikbaar was in Pro?
De twee belangrijkste:
- Alle bloatware die zichzelf blijft installeren
- GPO's die eerst wel van toepassing waren maar waarvan er steeds meer ineens alleen beschikbaar zijn in Enterprise
Dus, je mist bloatware die zichzelf blijft installeren? 8)7
Je hebt een komma teveel geplaatst. #taalpurist :+
Precies dit, zo professioneel is het niet meer, en Ultimate was het al niet meer sinds Windows 8.
Belachelijk, je koopt een product omdat daar een bepaalde functie inzit en later trekken ze die er zomaar uit... apart!

Zal wat zijn als je je auto bij de garage gaat ophalen en ze ineens je airco eruit hebben gehaald... "ja sorry meneer, die moet u na de eerste 80.000KM nog een keer los aanschaffen".
product windows 10 was ook heel anders bedoeld dan windows 7 of 8

Bij de server edition, gaat mogelijk de grafische omgeving helemaal weg.
Dit had ik vernomen met de eerste Windows server 2016 inside versies die nu als core versie kan gedownloaden.
Servers hebben ook helemaal geen GUI nodig. Een webinterface misschien (een beetje in de stijl als Windows Azure) en console access voor de rest. Servers zijn geen consumentenproducten.
Is niet waar, veel MS producten eisen een server met GUI o.a. Exchange
Het punt is volgens mij dat een GUI niet noodzakelijk is om het een bruikbaar product te maken. Exchange heeft bijvoorbeeld ook gewoon een Powershell module.
Al eens geprobeerd?

Stukje MS:
Non-Usage Scenarios

What shouldn't you use Server Core for? The main thing to understand is that Server Core is intended to run only the nine server roles listed previously. Nothing else. In other words, Server Core can't be used as a platform for running server applications such as Exchange Server, Microsoft SQL Server, or third-party server applications like SAP. You also can't use it for running Microsoft Office System applications or Microsoft Office SharePoint Server. And you can't (or at least shouldn't) use it to run custom applications you've developed in-house. In short, Server Core is not an application hosting platform.

This doesn't mean you can't install some applications on Server Core—you can, provided the applications have no dependency on the GUI. For example, you can install many of the following types of server applications onto Server Core:

En meteen geen support als je je niet houd aan best practises
eigenlijk alleen Exchange, en dat is een probleem van Exchange. Maw. ze, MS, moeten dat zelf oplossen en dan kan je prima een volledige GUI-loze Server maken. Zolang MS dezelfde functionaliteit beschikbaar maakt in Powershell als die er nu in de GUIs verwerkt zit kan je gewoon volledig een command-based server systeem maken.
Nope bijvoorbeeld SQL ook. En in de nieuwe 2016 server moet je kiezen voor gui of niet. Kan achteraf niet meer veranderd worden zoals in 2012 en r2. Alleen met een volledige herinstallatie.
BTW zelfs verplicht een gui als je de fax-server wil gebruiken. Wat een interne service van 2012r2 is.
https://technet.microsoft...ry/jj134193(v=ws.11).aspx
Fax is toch wel handig als bedrijf. Is als enige (hardcopie) nog steeds een wettig bewijs.

En dan bijvoorbeeld SAP. Ook toch geen kleine klant, en zo zijn er nog veel meer. Ik begrijp de filosofie wel maar ze blijven maar zwalken bij MS. Is met desktop minder erg is mijn mening, maar servers wil je graag lang stabiel houden. En met die verplichtte re-boots op W10 en ook de server versie 2016 zijn we weer terug bij Windows 95. Tis maar wat je onder een modern OS verstaat.

Ik neig steeds vaker naar een alternatief, want die dwingelandij van MS wordt ik zat. Zelfs een minimale hardware lock-in van Intel en MS is er al. Wordt steeds gekker.

Edit typo's

[Reactie gewijzigd door Bardman01 op 23 augustus 2017 11:56]

Is zeer afhankelijk van wat je wil draaien op die server, rollen als AD, DHCP, DNS, IIS die bij het OS horen zijn vaak geen enkel issue te installeren en te beheren in een Core installatie (Via Powershell of bijv. RSAT). MS is al zover dat er in de regel meer met Powershell kan dan via de GUI, ook in Exchange is dit bijv. het geval.

Maar bijv. zaken als Exchange en diverse system center applicaties kunnen dan weer niet geïnstalleerd worden op een Core server uit MS haar eigen product gamma. MS documenteert dit echter in de regel vrij netjes.

De grootste issues liggen echter imho bij 3rd party software, waar software vaak niet werkt onder Core installaties, maar waar dit ook nog eens vaak niet eens gedocumenteerd is. En support van die partijen je vaak ook nog eens vreemd aankijkt als je naar "Server Core" compatibiliteit" vraagt. Dan kan MS nog zo veel in Powershell e.d. stoppen, als 3rd Party developers niet mee werken ga je er echter niet verder komen.

@Bardman01 SQL is trouwens vanaf SQL 2012 gewoon op Windows Server Core te installeren, zie https://technet.microsoft...255&MSPPError=-2147217396

Voor een aantal features (o..a reporting service is wel een installatie met GUI nodig).
De grafische omgeving gaat op Server niet verwijdert worden. De eerst volgende release is gewoon een Server Core-only release, zodra een nieuwe LTSC-versie van Windows 10 om de hoek komt kijken komt er ook weer een Windows Server 201x uit met een grafische omgeving.
Nog niet. Veel servers leven nog op legacy code, maar ook daar gaat een omslag in komen. Server Core was eerst een bijzaak, maar begint momenteel de hoofdnoot te worden. En uiteindelijk zal het oude Windows Server de bijzaak worden. Dit gaat natuurlijk niet in één versie. ;)
Microsoft staat er nu niet bepaald om bekend om legacy software snel te beëindigen, ik verwacht dus niet dat ze überhaupt al serieus hebben gesproken over het droppen van de grafische interface voor Server. :)
Hoe werkt dat refs dan?
Als je w10 pro installeer kan je wel partities aanmaken maar niet kiezen voor ntfs en of Refs?
Je kan alleen maar partities aanmaken waarvan windows ntfs van maakt.
Je kunt inderdaad geen Refs Windows partitie maken, waarop je Windows kunt installeren.
Maar je kunt wel gewone Refs partities maken in Windows zelf of Diskpart.
Daarnaast worden na mijn weten Storage spaces altijd geformatteerd in Refs dus moeten we maar zien hoe deze toekomstige beperking in werkelijkheid uitpakt.
Hmmm. Ben het niet tegengekomen vorige week toen ik via diskmanagement een schijf volledig formatteerde.
Alleen ntfs of fat32.
Raar
Je kan het ook alleen gebruiken bij Windows 10 als je Storage spaces gaat gebruiken en dan moet je ook nog eens kiezen voor "2 Way Mirror", andere opties zullen in principe niet werken (iig niet toen ik het testte) en gaven foutmeldingen.

@JohanNL Ik moest ReFS specifiek selecteren trouwens, standaard stond deze gewoon op NTFS.
Je kunt ook met een registry edit een sub menu toevoegen aan de formatteer opties bij je harde schijven in Windows vanaf Windows 8.

Maar let op: ik heb dit '' trucje '' ook toegepast een jaar of 2 geleden op de toen der tijd RTM versie van
Windows 10 en ik kreeg door deze registry edit vreemde fouten en glitches in Windows zoals dat systeembeveiliging/systeemherstel TOTAAL onbruikbaar was en een Windows upgrade uitvoeren naar de volgende build wou ook niet.
Heb heeel lang lopen zoeken naar de oorzaak van die probleem maar ben er dus uiteindelijk achter gekomen doordat ik deze registry edit ook op een andere machine had gedaan.
Ik kon op die machine gelukkig gewoon de registry edit ongedaan maken en alles werkte weer, echter was dit niet het geval voor mijn machine waar deze registry edit al een hele tijd op stond.

Vind het toch vreemd dat dit, wat enkel een submenu toevoegt aan het format scherm zulke problemen kan veroorzaken!
Uiteindelijk is het van kwaad tot erger geworden en is mijn user profile corrupt geraakt op een of andere manier en was mijn Windows installatie praktisch onbruikbaar.
Dus wees gewaarschuwd... :)

Mocht je het toch willen proberen, zie: https://www.tenforums.com...ows-8-1-windows-10-a.html
Ik denk dat je harde schijf dit wel moet ondersteunen, denk ik!
Aparte drive als die een bepaald FS niet zou ondersteunen. Dan heb je denk ik gewoon een crappy disk. Kijk naar Linux, daar hoor je nóóit mensen dat hun disk bijvoorbeeld XFS niet ondersteunt.

Het zal de disk namelijk een rotzorg zijn
ReFs is alleen beschikbaar via de cmd prompt.
Dan nog heeft het niks te maken met of je drive het ondersteunt he. Wat jij zegt is hoe je er vanuit Windows bijkomt, wat logisch is want het is nog alpha/beta kwaliteit code als ik de rest van de reacties zo eens lees.
Disks zijn "block storage devices". Ze slaan data op in genummerde blokken; elk blok is 512 of 4096 bytes. File systemen geven (file)namen aan een verzameling van die blokken. Maar een disk weet dat helemaal niet; die blijft met nummers werken. De file system driver in ht OS doet de vertaling.
Ben wel benieuwd hoeveel mensen dit nu daadwerkelijk treft, ik verwacht zeer weinig. Zowel zakelijk als prive zie ik ReFS eigenlijk totaal niet gebruikt worden op een enkele uitzondering na, een aantal MS DPM 2016 implementaties gebruikt ReFS en bij Exchange 2016 wordt het ook aangeraden, echter enkel voor de disks waar de Mailbox databases op staan en de logs van diezelfde databases en dan ook nog eens met de "data integrety features" uitgezet.

Een vervanger van NTFS is het echter totaal (nog) niet en dat is denk ik ook een van de redenen waarom ze het deels verwijderen uit Pro, zo kun je niet booten van ReFS volumes, kun je veel applicaties niet installeren of starten vanaf ReFS volumes en wordt het eigenlijk alleen aangeraden om bepaalde vormen van data op te slaan op ReFS volumes maar bijv. geen execuatables die ook uitgevoerd moeten worden.
Ik heb liever ReFS partities dan GPT die verplicht zijn in windows bij grote opslagcapaciteiten.
Daarnaast denk ik dat wel meer mensen raid setups heeft voor series etc., heb zelf 2X2TB raid 0.
Disks die je wil gebruiken met ReFS moet je gewoon nog steeds initialiseren als GPT, ik zie het argument niet echt eigenlijk :o
ReFS is een FS, GPT is een disklabel. Dat zijn twee verschillende dingen ;-)
Nog enkele jaren en MS verliest hun markt omwille van kostprijs. Als ze doorgaan word het licensieren van een domme werkplek nog echt een apothekersrekening. Het is nu al niet eenvoudig (zeker niet in een EAP of EASL), versnippering maakt het enkel maar erger.
Ook System Image Backup wordt deprecated:
System Image Backup (SIB) Solution

We recommend that users use full-disk backup solutions from other vendors.
Nou zou dat niet veel gebruikt worden en functionaliteit beperkt zijn, maar wel goed om te weten als je het nog gebruikt, dat het eruit gaat.
Is dat hetzelfde als Windows Server Backup (In Windows Server) / Windows 7 backup (In Windows 10)?

Dat zou namelijk wel jammer zijn, vindt het ideaal om een bare metal recovery te kunnen doen en bovendien is deze tool eenvoudig, betrouwbaar en snel.
Misschien komt MS met een opvolger van NTFS voor client systemen? Refs lijkt me eerder een fs voor servers/big storage. Vergelijk het met Apfs van Apple, dit is een modern fs toegeschreven naar goede performance voor flash/ssd clients (watch/iphone/mac). Zou me niet verbazen als MS ook met een dergelijk nieuw modern client fs komt.
Dat hebben ze dan al jaren zéér goed geheim weten te houden. Een FS schrijf je namelijk niet "zomaar" even, daar gaat jaren inzitten als je het goed wil doen. En MS kan het zich niet veroorloven om het halfbakken te doen, dan verliezen ze in één klap een groot deel van hun klanten gok ik zo.

Op dit item kan niet meer gereageerd worden.


Apple iPhone X Google Pixel XL 2 LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*