NTFS vs. ReFS – hur man bestämmer vilken som ska användas

nu har du förmodligen hört talas om Microsofts relativt nya filsystem ”ReFS”. Introducerad med Windows Server 2012 försöker den överträffa NTFS i stabilitet och skalbarhet. Eftersom vi vanligtvis lagrar VHDX för flera virtuella maskiner i samma volym verkar det som om det passar bra med ReFS. Tyvärr gjorde det inte… i början. Microsoft har fortsatt att förbättra ReFS under de mellanliggande åren. Det har fått flera funktioner som distanserade det från NTFS. Med sin mognad, bör du börja använda den för Hyper-V? Du har mycket att tänka på innan du bestämmer dig.

Vad är ReFS?

monikern ”ReFS” betyder ”fjädrande filsystem”. Den innehåller inbyggda funktioner för att hjälpa till mot datakorruption. Microsofts docs-webbplats ger en detaljerad förklaring av ReFS och dess funktioner. En kort sammanfattning:

  • Integrity streams: ReFS använder kontrollsummor för att kontrollera om filen är skadad.
  • automatisk reparation: när ReFS upptäcker problem i en fil kommer den automatiskt att vidta korrigerande åtgärder.
  • prestandaförbättringar: under några speciella förhållanden ger ReFS prestandafördelar jämfört med NTFS.
  • mycket stor volym och filstöd: ReFS övre gränser överstiger NTFS utan att få samma prestanda träffar.
  • Spegelaccelererad paritet: Spegelaccelererad paritet använder mycket rå lagringsutrymme, men det är väldigt snabbt och mycket fjädrande.
  • Integration med lagringsutrymmen: många av ReFS funktioner fungerar bara till fullo i samband med lagringsutrymmen.

innan du blir upphetsad över några av de tidigare punkterna måste jag betona en sak: förutom kapacitetsgränser kräver ReFS lagringsutrymmen för att kunna göra sitt bästa arbete.

ReFS fördelar för Hyper-V

ReFS har funktioner som påskyndar vissa virtuella maskinaktiviteter.

  • Block kloning: genom min läsning är blockkloning i huvudsak en form av deduplikation. Men det fungerar inte som ett filsystemfilter eller skanner. Det är inte passivt vänta på godtyckliga data skriver eller regelbundet skanna filsystemet för dubbletter. Något måste aktivt åberopa det mot en specifik fil. Microsoft indikerar specifikt att det i hög grad kan påskynda checkpoint-sammanslagningar.
  • gles VDL (giltig datalängd): alla filsystem registrerar mängden utrymme som tilldelats en fil. ReFS använder VDL för att ange hur mycket av den filen som har data. Så när du instruerar Hyper-V att skapa en ny fast VHDX på ReFS kan den skapa hela filen på ungefär samma tid som att skapa en dynamiskt expanderande VHDX. Det kommer på samma sätt att gynna expansionsoperationer på dynamiskt expanderande VHDXs.

ta lite tid att gå igenom dessa funktioner. Tänk igenom deras totala applikationer.

ReFS vs. NTFS för Hyper-V: teknisk jämförelse

med den allmänna förklaringen ur vägen kan du nu göra en bättre bedömning av skillnaderna. Kontrollera först jämförelsetabellerna på Microsofts ReFS-översiktssida. För typiska Hyper-V-distributioner betyder de flesta skillnaderna väldigt lite. Till exempel behöver du förmodligen inte kvoter på dina Hyper-V-lagringsplatser. Låt oss göra ett eget bord, scoped mer lämpligt för Hyper-V:

  • ReFS vinner: riktigt stora lagringsplatser och riktigt stora VHDXs
  • ReFS vinner: miljöer med alltför hög förekomst av skapade, checkpointed eller sammanslagna VHDXs
  • ReFS vinner: lagringsutrymme och lagringsutrymmen direkta distributioner
  • NTFS vinner: distributioner med en volym
  • NTFS wins (potentiellt): blandade distributioner

jag tror att de flesta av dessa saker talar för sig själva. De två sista behöver förmodligen lite mer förklaring.

distributioner med en volym kräver NTFS

i detta sammanhang avser jag ”distribution med en volym” att betyda installationer där du har Hyper-V (inklusive dess hanteringsoperativsystem) och alla virtuella datorer på samma volym. Du kan inte formatera en startvolym med ReFS, och du kan inte heller placera en sidfil på ReFS. En sådan installation tillåter inte heller lagringsutrymmen eller lagringsutrymmen direkt, så det skulle ändå gå miste om de flesta av ReFS: s funktioner.

blandade distributioner kan kräva NTFS

vissa av oss har turen att distribuera Ingenting annat än virtuella maskiner på dedikerade lagringsplatser. Inte alla har det. Om din Hyper-V-lagringsvolym också är värd för filer för andra ändamål kan du behöva fortsätta med NTFS. Gå över den sista tabellen längst ner på översiktssidan. Det visar de egenskaper som du bara kan hitta i NTFS. För vanliga fildelningsscenarier förlorar du kvoter. Du kan ha äldre program som kräver NTFS utökade egenskaper eller korta namn. I dessa situationer kommer Endast NTFS att göra.

Obs: Om du har något alternativ, Använd inte samma värd för att köra icke-Hyper-V-Roller tillsammans med Hyper-V. Microsoft stöder inte blandning. På samma sätt separera Hyper-V VM på volymer bortsett från volymer som innehåller andra filtyper.

oväntat ReFS-beteende

det officiella innehållet går i vissa längder för att beskriva fördelarna med ReFS integritetsströmmar. Den använder kontrollsummor för att upptäcka filkorruption. Om den hittar problem, engagerar den sig i korrigerande åtgärder. På en lagringsutrymmen volym som använder skyddssystem, har det en möjlighet att åtgärda problemet. Det gör det med volymen online, vilket ger en sömlös upplevelse. Men vad händer när ReFS inte kan rätta till problemet? Det är där du måste betala verklig uppmärksamhet.

på översiktssidan använder dokumentationen exceptionellt vag formulering: ”ReFS tar bort korrupta data från namnområdet”. Integrity streams-sidan gör värre: ”om försöket misslyckas kommer ReFS att returnera ett fel.”När jag undersökte den här artikeln fick jag veta om en mer oroande aktivitet: ReFS raderar filer som den anser vara oföränderliga. Kommentarsektionen längst ner på den sidan innehåller en bekräftande rapport. Om du följer den kommentartråden genom hittar du en post från en Microsoft – Programhanterare som anger:

ReFS raderar filer i två scenarier:

  1. ReFS upptäcker metadatakorruption och det finns inget sätt att fixa det. Betydelse ReFS är inte på en lagringsutrymmen redundant volym där det kan fixa den skadade kopian.
  2. ReFS upptäcker datakorruption och Integritetsströmmen är aktiverad och det finns inget sätt att fixa det. Det betyder att om Integrity Stream inte är aktiverat kommer filen att vara tillgänglig om data är skadad eller inte. Om ReFS körs på en speglad volym med lagringsutrymmen, kommer den skadade kopian automatiskt att fixas.

resultatet: om ReFS beslutar att en VHDX har lidit oåterkallelig skada, kommer den att radera den. Det kommer inte att fråga, inte heller kommer det att ge dig någon möjlighet att försöka rädda vad du kan. Om ReFS inte stöds av Lagringsutrymmets redundans, har det inget sätt att utföra en reparation. Så, från ett perspektiv, som gör ReFS på icke-lagringsutrymmen ser ut som en mycket hög risk strategi. Men …

Tänk På Dina Säkerhetskopior!

du bör inte förbise svårighetsgraden i föregående avsnitt. Du bör dock inte låta det skrämma dig heller. Jag förstår verkligen att du kanske föredrar en delvis läsbar VHDX till en borttagen. För detta ändamål kan du helt enkelt inaktivera integritetsströmmar på dina VMs-filer. Jag har också ett annat förslag.

försumma inte dina säkerhetskopior! Om ReFS tar bort en fil, hämta den från backup. Om en VHDX går skadad på NTFS, hämta den från backup. Med ReFS vet du åtminstone att du har ett problem. Med NTFS kan problem lura mycket längre. Oavsett din konfiguration är det enda du kan lita på för att skydda dina data en solid säkerhetskopieringslösning.

När ska man välja NTFS för Hyper-V

du har nu tillräckligt med information för att fatta ett välgrundat beslut. Dessa villkor indikerar ett gott skick för NTFS:

  • konfigurationer som inte använder lagringsutrymmen, till exempel single-disk eller tillverkare RAID. Detta ensam gör inte en lufttät punkt; läs ” tänk på dina säkerhetskopior!”avsnittet ovan.
  • system med en volym (din värd har bara en C: volym)
  • blandade system (omkonfigurera för att separera Roller)
  • lagring på värdar äldre än 2016-ReFS var inte lika mogen På tidigare versioner. Detta ensam är inte en lufttät punkt.
  • din backup programleverantören stöder inte ReFS
  • om du är osäker på ReFS

allteftersom tiden går, NTFS kommer att förlora favorability över ReFS I Hyper-V distributioner. Men det betyder inte att NTFS har nått sitt slut. ReFS har häpnadsväckande högre gränser, men mycket få system använder mer än en bråkdel av vad NTFS kan erbjuda. ReFS har imponerande motståndskraft funktioner, men NTFS har också självläkande krafter och du har tillgång till RAID-teknik för att försvara sig mot datakorruption.

Microsoft kommer att fortsätta att utveckla ReFS. De kan så småningom positionera det som NTFS efterträdare. Från och med idag har de inte gjort det. Det ser inte ut som om de kommer att göra det imorgon heller. Känn dig inte pressad att flytta till ReFS före din komfortnivå.

När ska man välja ReFS för Hyper-V

vissa situationer gör ReFS till det tydliga valet för att lagra Hyper-V-data:

  • lagringsutrymmen (och lagringsutrymmen direkt) miljöer
  • extremt stora volymer
  • extremt stora VHDXs

du kan göra ytterligare prestandabaserade argument för ReFS i en miljö med en mycket hög churn av VHDX-filer. Överskatta dock inte effekten av dessa prestandaförbättringar. Den mest slående skillnaden visas när du skapar fasta VHDXs. För alla andra operationer måste du uppgradera din hårdvara för att uppnå meningsfull förbättring.

men jag vill inte släta över fördelarna med ReFS för mycket stora volymer. Om du har lagringsvolym på några terabyte och VHDX på till och med några hundra gigabyte, kommer ReFS sällan att slå NTFS betydligt. När du börjar tänka i termer av hundratals terabyte kommer NTFS sannolikt att visa flaskhalsar. Om du behöver trycka högre blir ReFS ditt enda val.

ReFS lyser verkligen när du kombinerar det med Storage Spaces Direct. Dess förmåga att automatiskt utföra en icke-störande online-reparation är verkligen imponerande. Å ena sidan utgör oddsen för störande datakorruption på moderna system en statistisk anomali. Å andra sidan bryr sig ingen som har lidit genom en sådan händelse verkligen hur osannolikt det var.

ReFS vs NTFS på Hyper-V Gästfilsystem

alla ovanstående handlar endast om Hyper-V: s lagring av virtuella maskiner. Vad sägs om ReFS i gästoperativsystem?

för att svara på den frågan måste vi gå tillbaka till ReFS styrkor. Hittills har vi bara tänkt på det när det gäller Hyper-V. gästerna har sina egna villkor och behov. Låt oss börja med att granska Microsofts ReFS-översikt. Specifikt följande:

”Microsoft har utvecklat NTFS specifikt för allmänt bruk med ett brett utbud av konfigurationer och arbetsbelastningar, men för kunder som speciellt kräver tillgänglighet, elasticitet och/eller skala som ReFS tillhandahåller stöder Microsoft ReFS för användning under följande konfigurationer och scenarier…”

jag lade tonvikten på den del som jag vill att du ska överväga. Meningen i sig får dig att tro att de kommer att fortsätta att lista några användningsområden, men de listar bara en: ”backup target”. De andra objekten på deras lista talar bara om lagringskonfigurationen. Så vi måste gräva tillbaka i meningen och dra ut de tre beskrivarna för att hjälpa oss att bestämma: ”tillgänglighet”, ”elasticitet” och ”skala”. Du kan kasta ut de två första direkt – du bör inte fokusera på lagringstillgänglighet och elasticitet i en VM. Det lämnar oss med”skala”. Så, riktigt stora volymer och riktigt stora filer. Kom ihåg att det betyder hundratals terabyte och uppåt.

för ett mer exakt beslut, läs igenom funktionsjämförelserna. Om något program som du vill använda i en gäst behöver funktioner som bara finns på NTFS, använd NTFS. Personligen använder jag fortfarande NTFS inuti gäster nästan uteslutande. ReFS behöver lagringsutrymmen för att göra sitt bästa arbete, och lagringsutrymmen gör sitt bästa arbete på det fysiska lagret.

kombinera ReFS med NTFS över Hyper-V-värd och gäster

Tänk på att filsystemet i en gäst inte har någon betydelse för värdens filsystem och vice versa. Såvitt Hyper-V vet är VHDXs kopplade till virtuella maskiner inget annat än ett bunt av datablock. Du kan använda vilken kombination som helst som fungerar.



+