Microsoft løfter sløret for nyt filsystem: ReFS

Og det lyder bare lækkert.

Det er tydeligt at man også har læst ZFS efter i kortene. Det er en god nyhed.

Mmmmh, blokniveau snapshots på et splitsekund.

Gør det systemet bedre rustet mod hacker angreb?

#3 ? Hvad gør NTFS eller FAT32 mod hackerangreb?

Det eneste forsvar kunne være, at mange hackere (jeg følger mig dum, at høre på) bruger Linux, så de derved ikke har understøttelse for det nye filsystem endnu.

Det rejser i øvrigt et interessant spørgsmål:
Hvornår mon vi vil se understøttelse for dette nye filsystem i Linux-/Unixsystemer?

hvad skete der med winfs, som oprindelig skulle komme med vista

#4

Et mere relevant spoergsmaal er nok, om MS har taenkt sig at lave dette til endnu et Windows-only filsystem.

#5
Det samme som der kommer til at ske med ReFS: udskudt, strippet for features og til sidst annulleret.

MS annulleret en del FS over årene: http://en.wikipedia.org/wiki/WinFS

#8 Så sandt. Jeg er bare bange for, at vi allerede kender svaret på det spørgsmål. :(

#8 Så sandt. Jeg er bare bange for, at vi allerede kender svaret på det spørgsmål. :(bjerh (#8)

Infinte loop detected, please abort.

Håber da godt nok at de får det spredt til andre systemer. Det er SÅ frustrerende at have USB stik til alle operativsystemer bare pga. forskellige filsystemer.

#10 Understøtter de ikke alle FAT32? Eller har i al fald "plugins" til det?

var der ikke noget med at dette filsystem er kun til data drev, og ikke system drev?

mener jeg har læst et eller andet sted at man ikke kan kan boote op i det... but maybe i'm wrong

#11
prøv lige at smide en en full HD film over på en USB med FAT32

But i want Win FS...

#11 exFAT!

var der ikke noget med at dette filsystem er kun til data drev, og ikke system drev?

mener jeg har læst et eller andet sted at man ikke kan kan boote op i det... but maybe i'm wrong

#11
prøv lige at smide en en full HD film over på en USB med FAT32cordion (#12)

Man kan vel boote fra alle drev som har en bootsector - og hvis der af en eller anden grund ikke skulle være det, læser UEFI fra en boot-sti frem for en sector, så det vil overraske mig meget hvis det ikke skulle være muligt - i hvert fald på nyere computere.

Er bange for at win8 bliver ny Vista/Win2000...

Well... der er en FAQ/Q&A eller hvad man vil kalde det.

Det ser ud som om ReFS er udviklet hovedsageligt til servere
og som #12 siger ser det ikke ud som om at det er muligt at boote fra den fra Windows 8 Server:

Q) Can I boot from ReFS in Windows Server 8?

No, this is not implemented or supported.

Q) Can ReFS be used on removable media or drives?

No, this is not implemented or supported
MSDN

#16
Hver 2. windows er crap i nyere tid, så hvis 7 er ok, så vil 8 være horribel :P

ReFS vil til at starte med kun være til data drev, det vil senere kunne bruges til OS drev også.

Det vil desuden kun være til Server versionen til at starte med, og komme til klienter senere.

#10 Understøtter de ikke alle FAT32? Eller har i al fald "plugins" til det?duppidat (#11)

FAT32 understøtter desværre ikke filer over 4GB. Og alternativerne (exFAT f.eks.) er ikke understøttet på mange systemer.

NTFS er f.eks. "Read only" i OSX, medmindre at man selv installerer software der giver den muligheden for at skrive, hvilket ikke altid er muligt i andre folks "miljøer"

#17.. Waat... No boot?
Omfg...

Kræver de så også UEFI for at se disken ? -.-

---

Lyde... Lød(!) ellers awesome ...
Specielt uden videre at kunne sprede data over flere maskiner (home clustering :D)

Er bange for at win8 bliver ny Vista/Win2000...Skak2000 (#16)

hvad var der galt med windows 2000?
Jeg synes nu det kørte lige så godt som windows xp or vil stadigt kunne bruges til de fleste ting som xp bruges til.
Den største ulempe er jo at det er mangelful på opdaterings siden i mange år efterhånden.
Vista derimod kan jeg godt se logikken med.

Forstår ikke at MS bruger et allerede åbent og testet filsystem istedet?
Er det fordi de skal frigive kildekode hvis de bruger et sådant fil system?
Det er jo som at genopfinde hjulet igen.

Hver 2. windows er crap i nyere tid, så hvis 7 er ok, så vil 8 være horribel :Puraniumdeer (#17)

Det er faktisk meget normalt, næsten inden for alle brancher at laver du noget radikalt nytænkning og design, er første udkast næsten altid fejlbehæftiget da der altid er ting man ikke har været istand til at forudse.

Microsoft har taget sig gevaldigt sammen efter Vista, og Win 8 ser allerede meget lovende ud, men jeg er ikke i tvivl om at der vil være problemer Specielt når man laver et system der skal køre på alt fra smartphones til servere.

Mener personligt at det er en mega fejl .. vil gerne have den hurtige opstart, men hvad skal jeg med touchskærm interface til den stationære PC der stadig står i mange hjem og arbejdspladser.

De skulle hellere lave 2 seperate systemer i stedet for at køre det hele sammen i 1 produkt.

Forstår ikke at MS bruger et allerede åbent og testet filsystem istedet?
Er det fordi de skal frigive kildekode hvis de bruger et sådant fil system?
Det er jo som at genopfinde hjulet igen.f-style (#21)

Som altid har de det jo med at lave deres egne standarder, og sørger for at deres kunder bliver bundet til deres produkter mest muligt.

Når det så er sagt, så mindes jeg ikke om et eksisterende filsystem som har samme features, samtidigt med at det er tilstrækkeligt modent.
Ellers kunne Btrfs være en god kandidat.

But i want Win FS...Coma (#13)

Nu er de to ting ret så forskellige. winfs er ikke et filsystem, men en applikation der kører oven på ntfs.

Understøtter de ikke alle FAT32?duppidat (#11)

Problemet er bare at FAT familien er nogle af de ringeste filsystemer der nogensinde er designet. Jeg kender i hvert fald ikke nogen der er ringere.

Masser af features der manglede i det oprindelige design er blevet tilføjet som lappeløsninger hen ad tiden. Det har ført til et umådeligt kompliceret system.

Begrænsninger i størrelse er blevet "løst" ved blot at gøre blokpointers større uden at ændre på de grundlæggende datastrukturer, der gør at det ikke skallerer særligt godt.

En linket liste af blokke var et overskueligt problem dengang længden af den lænkede liste var begrænset af at blokpointers kun var 12 bits, og listen derfor aldrig kunne blive særligt lang.

I dag bruges der 32 bits blokpointers, og de bruger stadig den samme lænkede liste. Listen kunne være en million gange så lang som da FAT oprindeligt blev designet (hvis ellers de lige ville gøre noget ved 4GB begrænsningen). Random access i en lænket liste af den længde er ikke effektivt.

Derudover er der en række features som vi i dag tager for givet, men som ikke var supporteret i den oprindelige FAT version og er lavet som lappeløsninger, der gør filsystemet mere kompliceret.

Af features der er tilføjet vha. af lappeløsninger kan nævnes:
- Mulighed for at slette filer (uden reformatering)
- Mulighed for at lave directories
- Mulighed for karakterer som ikke var inkluderet i 7-bit ascii
- Mulighed for navne længere end 8+3 karakterer

De har snakket om nyt filsystem siden Windows Vista blev kaldt "Longhorn" - Men jeg synes da godt nok også at det var på tiden vi løftede baren!

Så også gerne at de prøvede HELT fra bunden, så man ikke byggede videre på noget gammelt.

HFS er fra 1985 som eksempel..

Hvad gør NTFS eller FAT32 mod hackerangreb?bjerh (#4)

NTFS giver mulighed for at kontrollere adgang til filer. Det gør det nye vel også. Men det er næppe pointen.

#17

En disk med OS har næppe det store behov for de nye features.

Forstår ikke at MS bruger et allerede åbent og testet filsystem istedet?
Er det fordi de skal frigive kildekode hvis de bruger et sådant fil system?f-style (#21)

Der skal vel også nyudvikles inden for software af og til? Ellers kunne man jo sige det samme om alle programmer, OSer etc. Men det er naturligvis et problem med segmenteringen.

Er bange for at win8 bliver ny Vista/Win2000...Skak2000 (#16)

Jeg tilslutter mig #21 - Windows 2000 virkede da fint.

Forstår ikke at MS bruger et allerede åbent og testet filsystem istedet?
Er det fordi de skal frigive kildekode hvis de bruger et sådant fil system?
Det er jo som at genopfinde hjulet igen.f-style (#21)

Med et åbent filsystem var koden jo allerede frigivet, så det er næppe årsagen.

Det er nok mere sektionen "Code reuse and compatibility" i det linkede som er årsagen.

Hvad er der dog galt med FAT16?.. Min K6-2 kører ihvertfald skide godt! Turbo-mode FTW :D

Hvorfor kan de ikke bare tage en af de mange udemærkede GNU/ linux filsystemer og tilføje det som en option...
Det som irreterer mig klart mest ved ntfs er hastigheden og at jeg stadig skal/ kan defragmentere mit drev..

Forstår ikke at MS bruger et allerede åbent og testet filsystem istedet?
Er det fordi de skal frigive kildekode hvis de bruger et sådant fil system?
Det er jo som at genopfinde hjulet igen.f-style (#21)

Man kunne have valgt at benytte sig af ZFS. Det ville ikke kræve at koden skulle frigives med mindre de laver ændringer. Humlen er nu nok at de ønsker at beholde en vis bagudkompabilitet.

Storage pooling lyder interessant. Såfremt det ikke kommer med samme begrænsninger for hastigheden som i WHS.

Kommer mine spil til at load hurtigere hvis ja = happy, nej = not care :P

#36

Spiller du på Windows Server??

Det er faktisk meget normalt, næsten inden for alle brancher at laver du noget radikalt nytænkning og design, er første udkast næsten altid fejlbehæftiget da der altid er ting man ikke har været istand til at forudse.

Microsoft har taget sig gevaldigt sammen efter Vista, og Win 8 ser allerede meget lovende ud, men jeg er ikke i tvivl om at der vil være problemer Specielt når man laver et system der skal køre på alt fra smartphones til servere.

Mener personligt at det er en mega fejl .. vil gerne have den hurtige opstart, men hvad skal jeg med touchskærm interface til den stationære PC der stadig står i mange hjem og arbejdspladser.

De skulle hellere lave 2 seperate systemer i stedet for at køre det hele sammen i 1 produkt.Dali_lb (#22)

Husk nu at du kan skifte mellem metro UI og det vel kendte windows UI. Det er ikke et kompromi men en VALGMULIGHED. Kan du ikke lide metro UI så skift til windows UI og omvendt. Personligt vil jeg hellere have valgfrihed end at det er 100% fastsat. Kan også godt se fidusen med metro UI også som media center da det bliver nemmere at betjene med f.eks. en fjernbetjening. At det også kommer til at køre på ARM og tablets mener jeg er det største plus nogensinde. Så kan du virkelig køre samme windows setup på alle dine enheder uden at UI'et skal skifte fra enhed til enhed. Metro er da nytænkning rent UI mæssigt i rigtig lang tid fra MS's side og det bliver spændende at prøve når MS begynder på deres RC udgave.
Det ser ihvertfald rigtig lovende ud, ud fra det jeg har set indtil videre og tror det kommer op på samme højde og niveau som windows 7. Især når systemkravene er sænket markant hvilket er godt (så det kører flydende selv på mindre krævende enheder). Det var jo en af vista's største kritik punkter.

"Det nye filsystem er designet fra bunden af, men med udgangspunkt i NTFS" ... gad vide om det så virkelig også ER designet fra bunden af, eller om det bare er NTFS + features?

Ja ja, men lad os nu lige få nogle tal på bordet.

Maximum size of a single file
2^64-1 bytes

Maximum size of a single volume
Format supports 2^78 bytes with 16KB cluster size (2^64 * 16 * 2^10). Windows stack addressing allows 2^64 bytes

Maximum number of files in a directory
2^64

Maximum number of directories in a volume
2^64

Maximum file name length
32K unicode characters

Maximum path length
32K

Maximum size of any storage pool
4 PB

Maximum number of storage pools in a system
No limit

Maximum number of spaces in a storage pool
No limitKilde

Eller på dansk: Filstørrelse på op til 18 exabyte. Op til 17 trillioner mapper på et drev. 17 trillioner filer i en mappe. (ved ikke om de 2 x17 trillioner er på samme tid, men der er nu nok ingen der vil forsøge at efterprøve teorien - Ever!)
Et filnavn kan bestå af op til 32.000 Unicode-tegn. Et filadresse på op til 32.000 Unicode-tign. (de 2 er nok ikke på samme tid, men så igen...).

Antal drev i en pool: Uendelig. Nok mest bundkortet der sætter grænsen her. Max størrelse på en pool: 4 petabyte (4000 terabytes).
Man kan sætte drev med forskellige interface sammen i samme pool, som SATA og Serial Attached SCSI. For hver pool kan man definere en selvstændig redundans-politik.

Nyt filsystem til Windows 8 kan gemme 18 exabyte

Edit: Nogen der kan fortælle mig hvilken fejl der er i udregningerne?
Ifølge mit hoved, kan en fil altså være flere 1000 gange større end den samlede diskkapacitet

#36

Spiller du på Windows Server??arne_v (#37)

Det gjorde jeg i en kort periode da mit bundkort brændte af ... Bevares, det var kun lidt EVE og meget solitaire ;)

Et filnavn kan bestå af op til 32.000 Unicode-tegn.bbb2020 (#40)

Gad vide om grænsen nu også er den samme uanset hvilke unicode tegn man anvender. UTF-8 og UTF-16 bruger et variabelt antal bytes per tegn. Hvis begrænsningen f.eks. er 64KB (ikke nogen urealistisk størrelse, da det nu engang er hvad man kan angive med 16 bits), så vil man kunne have 32767 16-bit words. Med UTF-16 bliver det til 32767 unicode tegn hvis man holder sig til dem der kan kodes med et enkelt 16-bit word. Men hvis man bruger de højere unicode tegn kan man kun bruger op til 16383 unicode tegn.

Hvis de har valgt at gemme data som UTF-16, så gemmer de nok længden af den indkodede version og ikke antallet af unicode tegn, da sidstnævnte ville kræve at man parsede navnet hver gang man ville vide hvor meget det fyldte.

UTF-32 er den eneste indkodning hvor unicode tegn har en fast længde. Men med den indkodning ville 32K unicode tegn fylde 128KB. Det lyder ikke som det mest sandsynlige valg.

Indtil jeg ser dokumentation for andet gætter jeg på de bruger UTF-16 og begrænsningen er 32K 16-bit words. Dybest set er det ikke noget som de fleste af os ikke har nogen grund til at bekymre os om. Hvis man synes der er grund til at skrive en roman i et filnavn, så gør man noget galt.

#42

I NTFS er begrænsningen 32767 x 16 bit enheder (UTF-16) for den fulde path.

Skal vi ikke gætte på at det nye system er det samme.

Derudover er der en række features som vi i dag tager for givet, men som ikke var supporteret i den oprindelige FAT version og er lavet som lappeløsninger, der gør filsystemet mere kompliceret.

Af features der er tilføjet vha. af lappeløsninger kan nævnes:
- Mulighed for at slette filer (uden reformatering)
- Mulighed for at lave directories
- Mulighed for karakterer som ikke var inkluderet i 7-bit ascii
kasperd (#25)

FAT8 ??

For DOS og FAT12 har vel altid understøttet slet, dirs og 128-255 tegn.

For DOS og FAT12 har vel altid understøttet slet, dirs og 128-255 tegn.arne_v (#44)

Udfra hvad jeg har læst tidligere, så er det ikke tilfældet.

Muligheden for at slette filer skulle være blevet introduceret i DOS version 1.1. Måden det var implementeret på var ved at overskrive det første tegn af filnavnet med 0xE5.

Support for directories skulle være noget der blev indført i DOS 2.0.

Muligheden for at bruge tegn udover 7 bits ascii har ikke været til stede på det tidspunkt hvor support for at slette filer blev indført. Hvis man havde haft support for 8 bits ascii på det punkt ville man ikke have fundet på at skrive 0xE5 over det første tegn for at slette en fil.

Men muligheden for 8 bits ascii kom på et senere tidspunkt. Og du kan godt bruge tegn 0xE5 i filnavne. Dog er der specialtilfælde i koden til at håndtere hvis det første tegn i et filnavn er 0xE5, så skrives der på disken 0x05 i stedet for.

Godt nok har jeg ikke selv brugt DOS versioner før version 3.30. Men når man kigger på APIer og det fysiske format af filsystemet, så bærer det tydligt præg af at de features er tilføjet senere.

F.eks. er den måde 0xE5 tegnet håndteres på ikke noget der giver den mindste mening hvis det havde været designet med support for sletning af filer i første omgang. Der må have været et eller andet omkring bagudkompatibilitet som er årsagen til at man har valgt at gøre det på den måde.

Hvad angår directories er roddirectoriet på et FAT system implementeret på en helt anden måde end alle andre directories. Rod directoriet får en fast størrelse når filsystemet oprettes og kan aldrig ændres. Det sætter en fast begrænsning på hvor mange filer og underdirectories der kan være i roden. Alle andre directories alloceres der plads til efter behov således at man ikke spilder plads hvis man ikke har brug for så mange filer men stadigvæk har mulighed for at tilføje så mange som man har lyst til.

Den eneste fornuftige forklaring på at roddirectoriet har den slags begrænsninger må være bagudkompatibilitet. Det bærer præg af at roddirectoriet blev designet tidligere end underdirectories.

Jeg tror nok at med FAT32 blev roddirectoriet lavet om så det fungerer på samme måde som underdirectories. Men FAT32 skulle jo heller ikke være bagudkompatibel på samme måde. Og FAT32 kom få år efter supporten for lange filnavne. Support for lange filnavne brugte ekstra directoryindgange, så man fik hurtigere roden fyldt op efter introduktionen af Windows 95.

Hvis man kigger på APIerne er der nogle gamle APIer for tilgang af filer som kun understøtter angivelse af drevbogstav og filnavn, men intet directory. Det kan stort set kun forklares med at de APIer er fra før directories blev indført.

Hvorfor er det at DOS som det eneste (mig bekendt) operativ system husker på et aktivt directory per drev og ikke per process som andre operativsystemer? Jeg tror det er af hensyn til gamle programmer som bruger den API hvor man kun angiver drevbogstav og filnavn. Så kan man sætte det aktive directory på hvert filsystem inden man starter sådan en applikation, og den kan dermed tilgå de filer man har brug for.

I like turtles....

On topic: Ser da interessant ud! Nogen der ved noget om hvad det evt. vil betyde for read/write-hastigheden? Nu er HDDs ikke lige mit speciale, så det kan godt være at jeg har misforstået noget ;)

Fin liste over nye featues. Gad vide om man kan lave en lign. liste over ting der mangler?

named streams
object IDs
short names
compression
file level encryption (EFS)
user data transactions
sparse files
hard-links
extended attributes
quotas

Jeg tilslutter mig #21 - Windows 2000 virkede da fint.arne_v (#30)

Nu har der været en del quotes på den første post...

Uden at kende tankerne bag den første, tror jeg at vedkommet har haft Windows ME (Millennium Edition) i hovedet.

Det var simpelthen ikke til at bruge (Det lå da på højde med Vista.)

Dertil vil jeg tilslutte mig #21, da jeg altid har været glad for 2000.

Uden at kende tankerne bag den første, tror jeg at vedkommet har haft Windows ME (Millennium Edition) i hovedet.exetico (#48)

Det er da også noget af en fejl at begå. Windows ME var vist bare en grafisk brugerflade til DOS 7.x hvorimod Windows 2000 var et egentligt operativsystem.

Så vidt jeg husker var Windows 2000 blot Windows NT med en ny brugerflade der lignede den som Windows 95, 98, ME brugte.

#49. Mmmm Windows NT4 workstation/server... Se det spillede bare. På min gamle arbejdsplads stod der en uåbnet NT4 licens! Vi snakker 2010! Collecter's item.