NTFS vs ReFS – Hvordan Bestemme Seg For Å Bruke

nå har du sannsynligvis hørt Om Microsofts relativt nye filsystem «ReFS». Introdusert Med Windows Server 2012, søker DEN å overgå NTFS i stabilitet og skalerbarhet. Siden Vi vanligvis lagrer VHDXs for flere virtuelle maskiner i samme volum, virker det som om det passer godt Sammen Med ReFS. Dessverre gjorde det ikke … i begynnelsen. Microsoft har fortsatt å forbedre ReFS i de mellomliggende årene. Det har fått flere funksjoner som distanserte DEN FRA NTFS. Med sin modning, bør du begynne Å bruke Den Til Hyper-V? Du har mye å vurdere før du gjør det besluttsomhet.

Hva Er ReFS?

monikeren «ReFS» betyr «resilient file system». Det inkluderer innebygde funksjoner for å hjelpe mot data korrupsjon. Microsofts docs-nettsted gir en detaljert forklaring på ReFS og dens funksjoner. En kort oppsummering:

• Integritetsstrømmer: ReFS bruker sjekksummer for å sjekke om filkorrupsjon.
• Automatisk reparasjon: Når ReFS oppdager problemer i en fil, vil den automatisk vedta korrigerende tiltak.
• Ytelsesforbedringer: I noen få spesielle forhold gir ReFS ytelsesfordeler over NTFS.
• Veldig stort volum og filstøtte: ReFS øvre grenser overskrider NTFS uten å pådra seg samme ytelsesslag.
• Speilakselerert paritet: Speilakselerert paritet bruker mye rå lagringsplass, men det er veldig raskt og veldig motstandsdyktig.
• Integrasjon Med Lagringsplasser: Mange Av ReFS-funksjonene fungerer bare fullt ut i forbindelse med Lagringsplasser.

før du blir begeistret for noen av de tidligere punktene, må jeg understreke en ting: Bortsett fra kapasitetsgrenser, Krever ReFS Lagringsplasser for å gjøre sitt beste arbeid.

ReFS Fordeler For Hyper-V

ReFS har funksjoner som akselererer noen virtuelle maskinaktiviteter.

• Blokk kloning: ved min lesing er blokk kloning i hovedsak en form for de-duplisering. Men det fungerer ikke som et filsystemfilter eller skanner. Det trenger ikke passivt vente på vilkårlig data skriver eller jevne skanne filsystemet for duplikater. Noe må aktivt påkalle det mot en bestemt fil. Microsoft indikerer spesielt at det kan i stor grad fart sjekkpunkt fusjonerer.
• Sparsom VDL( gyldig datalengde): alle filsystemer registrerer hvor mye plass som er tildelt en fil. ReFS bruker VDL for å angi hvor mye av denne filen har data. Så når Du instruerer Hyper-V for å opprette en ny fast VHDX på ReFS, kan den opprette hele filen på omtrent samme tid som å skape en dynamisk ekspanderende VHDX. Det vil også være til nytte for ekspansjonsoperasjoner på dynamisk voksende VHDXs.

Ta litt tid å gå over disse funksjonene. Tenk gjennom deres totale applikasjoner.

ReFS vs NTFS For Hyper-V: Teknisk Sammenligning

med den generelle forklaringen ut av veien, nå kan du gjøre en bedre vurdering av forskjellene. Sjekk først sammenligningstabellene På Microsofts Oversiktsside For ReFS. For typiske Hyper-V-distribusjoner betyr de fleste forskjellene svært lite. For eksempel trenger du sannsynligvis ikke kvoter på Hyper-V-lagringsstedene dine. La oss lage et eget bord, scoped mer hensiktsmessig For Hyper-V:

• ReFS wins: Virkelig store lagringsplasser Og virkelig store VHDXs
• ReFS wins: Miljøer med svært høy forekomst av opprettet, merket eller sammenslåtte VHDXs
• ReFS wins: Lagringsplass Og Lagringsplasser Direkte distribusjoner
• NTFS wins: Enkeltvolum distribusjoner
• ntfs wins (potensielt): mixed-purpose distribusjoner

Jeg Tror De Fleste Av Disse Tingene Snakker For Seg Selv. De to siste trenger sannsynligvis litt mer forklaring.

Enkeltvolumutplasseringer Krever NTFS

I denne sammenheng har jeg tenkt «enkeltvolumutplassering» til å bety installasjoner der Du Har Hyper-V (inkludert administrasjonsoperativsystemet) og alle Vm-er på samme volum. Du kan ikke formatere et oppstartsvolum Med ReFS, og du kan heller ikke plassere en sidefil på ReFS. En slik installasjon tillater heller ikke Lagringsplasser Eller Lagringsplasser Direkte, så det ville gå glipp av de fleste ReFS evner uansett.

Distribusjoner Med Blandet Formål Kan Kreve NTFS

Noen av oss har lykken til å distribuere bare virtuelle maskiner på dedikerte lagringssteder. Ikke alle har det. Hvis Hyper-V-lagringsvolumet også er vert for filer til andre formål, må du kanskje fortsette MED NTFS. Gå over den siste tabellen nederst på oversiktssiden. Det viser egenskapene som du bare finner I NTFS. For standard fildeling scenarier, mister du kvoter. Du kan ha eldre programmer som krever NTFS utvidede egenskaper eller korte navn. I disse situasjonene vil BARE NTFS gjøre.

Merk: Hvis du har noe alternativ, må Du ikke bruke den samme verten til å kjøre ikke-Hyper-V-roller sammen Med Hyper-V. Microsoft støtter ikke miksing. På samme måte skille Hyper-V Vm på volumer bortsett fra volumer som holder andre filtyper.

Uventet ReFS-Oppførsel

det offisielle innholdet går til noen lengder for å beskrive fordelene Med ReFS integritetsstrømmer. Den bruker sjekksummer for å oppdage fil korrupsjon. Hvis det finner problemer, engasjerer det seg i korrigerende tiltak. På En Lagringsplass volum som bruker beskyttende ordninger, har det en mulighet til å løse problemet. Det gjør det med volumet på nettet, og gir en sømløs opplevelse. Men, hva skjer når ReFS ikke kan rette opp problemet? Det er her du må betale ekte oppmerksomhet.

på oversiktssiden bruker dokumentasjonen eksepsjonelt vag ordlyd: «ReFS fjerner korrupte data fra navneområdet». Integrity streams-siden gjør verre: «Hvis forsøket mislykkes, Vil ReFS returnere en feil.»Mens jeg undersøkte denne artikkelen, ble jeg fortalt om en mer urolig aktivitet: ReFS sletter filer som den anser unfixable. Kommentarfeltet nederst på denne siden inneholder en bekreftende rapport. Hvis du følger denne kommentartråden gjennom, finner du en oppføring Fra En Microsoft program manager som sier:

ReFS sletter filer i to scenarier:

1. ReFS oppdager metadata korrupsjon OG det er ingen måte å fikse det. Betydning ReFS er ikke på Et Lagringsrom overflødig volum der det kan fikse den ødelagte kopien.
2. ReFS oppdager dataødeleggelse og Integritetsstrøm er aktivert, og det er ingen måte å fikse det på. Betydning hvis Integrity Stream ikke er aktivert, vil filen være tilgjengelig om data er skadet eller ikke. Hvis ReFS kjører på et speilet volum ved Hjelp Av Lagringsplasser, blir den ødelagte kopien automatisk løst.

resultatet: Hvis ReFS bestemmer at EN VHDX har påført uopprettelig skade, vil den slette den. Det vil ikke spørre, og det vil heller ikke gi deg noen mulighet til å prøve å redde det du kan. Hvis ReFS ikke støttes av Lagringsplassens redundans, har den ingen måte å utføre en reparasjon på. Så, fra ett perspektiv, som gjør ReFS på ikke-Lagringsplass Ser ut som en svært høy risiko tilnærming. Men…

Husk Sikkerhetskopiene Dine!

du bør ikke overse alvorlighetsgraden av den forrige delen. Du bør imidlertid ikke la det skremme deg bort heller. Jeg forstår sikkert at du kanskje foretrekker en delvis lesbar VHDX til en slettet. Til det formål kan du bare deaktivere integritetsstrømmer på VMs-filene dine. Jeg har også et annet forslag.

ikke forsøm sikkerhetskopiene dine! Hvis ReFS sletter en fil, henter du den fra sikkerhetskopien. Hvis EN VHDX går korrupt PÅ NTFS, hente den fra backup. Med ReFS vet du i det minste at du har et problem. MED NTFS kan problemer lure mye lenger. Uansett konfigurasjon, det eneste du kan stole på for å beskytte dine data er en solid backup løsning.

NÅR DU Skal Velge NTFS For Hyper-V

Har du nå nok informasjon til å ta en informert beslutning. Disse forholdene indikerer en god tilstand FOR NTFS:

• Konfigurasjoner som ikke bruker Lagringsplass, for eksempel en-disk ELLER produsent RAID. Dette alene gjør ikke et lufttett punkt; vennligst les «Mind Sikkerhetskopiene!»seksjon ovenfor.
• enkeltvolumsystemer (verten din har bare et c: volum)
• Systemer Med Blandet formål(vennligst omkonfigurere til separate roller)
• Lagring på verter eldre enn 2016-ReFS var ikke så moden på tidligere versjoner. Dette alene er ikke et lufttett punkt.
• leverandøren av sikkerhetskopieringsprogrammet støtter ikke ReFS
• hvis Du er usikker På ReFS

ETTER hvert som TIDEN går, VIL NTFS miste fordelbarhet over ReFS i Hyper-V-distribusjoner. MEN DET betyr ikke AT NTFS har nådd sin ende. ReFS har svimlende høyere grenser, men svært få systemer bruker mer enn en brøkdel av HVA NTFS kan tilby. ReFS har imponerende resiliensfunksjoner, MEN NTFS har også selvhelbredende krefter, og du har tilgang til RAID-teknologier for å forsvare seg mot data korrupsjon.

Microsoft vil fortsette å utvikle ReFS. De kan til slutt posisjonere DEN SOM NTFS etterfølger. Per i dag, de har ikke gjort det. Det ser ikke ut til at de gjør det i morgen heller. Ikke føl deg presset til å flytte Til ReFS foran ditt komfortnivå.

Når Skal Du Velge ReFS For Hyper-V

Noen situasjoner Gjør ReFS det klare valget for lagring Av Hyper-V-data:

• Lagringsplasser (Og Lagringsplasser Direkte) miljøer
• Ekstremt store volumer
• Ekstremt store VHDXs

Du kan lage et ekstra ytelsesbasert argument for ReFS i et miljø med svært høy churn AV VHDX-filer. Overvurder imidlertid ikke effekten av disse ytelsesforbedringene. Den mest slående forskjellen vises når du oppretter faste VHDXs. For alle andre operasjoner må du oppgradere maskinvaren for å oppnå meningsfylt forbedring.

jeg vil imidlertid ikke glatte over Fordelene Med ReFS for svært store volumer. Hvis du har lagringsvolum på noen få terabyte og VHDXs på enda noen få hundre gigabyte, Vil ReFS sjelden slå NTFS betydelig. NÅR DU begynner å tenke i form av hundrevis av terabyte, NTFS vil trolig vise flaskehalser. Hvis du trenger å presse høyere, Blir ReFS ditt eneste valg.

ReFS skinner virkelig når du kombinerer Det Med Storage Spaces Direct. Dens evne til automatisk å utføre en ikke-forstyrrende online reparasjon er virkelig imponerende. På den ene siden utgjør oddsen for forstyrrende datakorrupsjon på moderne systemer en statistisk anomali. På den andre, ingen som har lidd gjennom en slik hendelse virkelig bryr seg hvor usannsynlig det var.

ReFS vs NTFS På Hyper-V Gjest Filsystemer

alle de ovennevnte avtaler bare Med Hyper-V lagring av virtuelle maskiner. Hva med ReFS i gjesteoperativsystemer?

for å svare på det spørsmålet, må vi gå tilbake til ReFS styrker. Så langt har Vi bare tenkt på Det Når Det Gjelder Hyper-V. Gjestene har sine egne forhold og behov. La oss starte med å gjennomgå Microsofts ReFS oversikt. Spesielt følgende:

«Microsoft har utviklet NTFS spesielt for generell bruk med et bredt spekter av konfigurasjoner og arbeidsbelastninger, Men for kunder som spesielt krever tilgjengelighet, fleksibilitet og/eller skala Som ReFS gir, Støtter Microsoft ReFS for bruk under følgende konfigurasjoner og scenarier…»

jeg la vekt på den delen som jeg vil at du skal vurdere. Setningen i seg selv gjør at du tror at de vil fortsette å liste noen bruksområder, men de viser bare en: «backup target». De andre elementene på listen snakker bare om lagringskonfigurasjonen. Så, vi må grave tilbake i setningen og trekke ut de tre beskrivelsene for å hjelpe oss med å bestemme: «tilgjengelighet», «resiliency» og «scale». Du kan kaste ut de to første med en gang-du bør ikke fokusere på lagringstilgjengelighet og fleksibilitet i EN VM. Det etterlater oss med «skala». Så, virkelig store volumer og virkelig store filer. Husk at det betyr hundrevis av terabyte og oppover.

for en mer nøyaktig beslutning, les gjennom funksjonen sammenligninger. HVIS et program du vil bruke i en gjest, trenger funksjoner som bare finnes PÅ NTFS, bruker DU NTFS. PERSONLIG bruker JEG FORTSATT NTFS inne gjester nesten utelukkende. ReFS trenger Lagringsplasser for å gjøre sitt beste arbeid, Og Lagringsplasser gjør sitt beste arbeid på det fysiske laget.

Kombinere ReFS med NTFS over Hyper-V Vert Og Gjester

Husk at filsystemet inne i en gjest ikke har noen betydning for vertens filsystem, og omvendt. Så vidt Hyper-V vet, Er Vhdxer knyttet til virtuelle maskiner ikke noe annet enn et bunt av datablokker. Du kan bruke hvilken som helst kombinasjon som fungerer.