Delen via


Blokklonen

Een blok-klonen bewerking geeft het bestandssysteem de opdracht om een bereik van bytes van het bestand te kopiëren voor een toepassing. Het doelbestand kan hetzelfde zijn als of afwijken van het bronbestand.

Een bestandssysteem beheert de toewijzingen van Clusters en Extentsen kan de kopie mogelijk uitvoeren door het virtuele clusternummer (VCN) te wijzigen in LCN-toewijzingen (logical cluster number) als een goedkope metagegevensbewerking in plaats van de onderliggende bestandsgegevens te lezen en te schrijven. Hierdoor kan de kopie sneller worden voltooid en wordt er minder I/O gegenereerd naar de onderliggende opslag. Bovendien kunnen meerdere bestanden nu logische cluster delen na de blokklonering, waardoor capaciteit wordt bespaard door identieke clusters niet meerdere keren op schijf op te slaan.

Een blokklonenbewerking verbreekt de isolatie tussen bestanden niet. Nadat een blokklonering is voltooid, worden schrijfbewerkingen naar het bronbestand niet weergegeven in het doelbestand, of andersom.

Blokklonen is alleen beschikbaar op het ReFS-bestandssysteem type vanaf Windows Server 2016. Vanaf de update voor Windows 11 Moment 5 (KB5034848) en latere versies van Windows-client en Windows Server, vindt het klonen van blokken native plaats in ondersteunde kopieerbewerkingen van Windows.

Klonen op ReFS blokkeren

Vanaf Windows Server 2016 implementeert ReFS blokklonen door logische clusters (dat wil zeggen fysieke locaties op een volume) te herleiden van het brongebied naar het doelgebied. Vervolgens wordt een mechanisme voor schrijfgebaseerde toewijzing gebruikt om isolatie tussen die regio's te garanderen. De bron- en doelregio's kunnen zich in dezelfde of verschillende bestanden bevinden.

Voor deze implementatie moeten de begin- en eindbestandsoffset worden uitgelijnd met clustergrenzen. In ReFS vanaf Windows Server 2016 zijn clusters standaard 4 kB groot, maar kunnen ze desgewenst worden ingesteld op 64 kB. De clustergrootte is een volumebrede parameter die is ingesteld op het moment van formatteren.

Gevolgen voor clustergrootte en prestaties

De clustergrootte van een ReFS-volume heeft rechtstreeks invloed op het gedrag van blokkopiëren en de prestatie-eigenschappen.

  • Standaardclustergrootte: 4 kB (aanbevolen voor de meeste workloads)
  • Alternatieve clustergrootte: 64 kB (geschikt voor grote, sequentiële I/O-workloads)

De clustergrootte bepaalt de granulariteit waarmee blokklonen en copy-on-write-bewerkingen plaatsvinden. Wanneer een schrijfbewerking wordt uitgevoerd naar een bestandsgedeelte dat clusters deelt met een ander bestand (na een blokkloon), gebruikt ReFS een mechanisme voor alloceren bij schrijfproces dat op clusterniveau werkt:

  • Alleen het gewijzigde cluster wordt gedupliceerd en naar een nieuwe fysieke locatie geschreven
  • Niet-gewijzigde clusters binnen dezelfde regio blijven gedeeld
  • Dit gedrag is van toepassing, ongeacht of blokklonen expliciet is gestart via FSCTL_DUPLICATE_EXTENTS_TO_FILE of automatisch door het systeem (Windows 11 Moment 5 en hoger)

Prestatie-overwegingen

De keuze van de clustergrootte heeft belangrijke gevolgen voor prestaties en ruimteverbruik:

  • 4 KB-clusters: zorgen voor een betere ruimteefficiëntie voor workloads met kleine, willekeurige schrijfbewerkingen (KB naar MB-bereik), omdat er slechts 4 kB per gewijzigd cluster wordt gedupliceerd. Dit kan echter leiden tot frequentere copy-on-write-bewerkingen.
  • 64 KB-clusters: verminder de overhead van metagegevens en verbeter de prestaties van de sequentiële I/O, maar kan ertoe leiden dat maximaal 64 kB wordt gedupliceerd voor elke schrijfbewerking naar een gedeelde regio, zelfs als de schrijfbewerking kleiner is dan 64 kB.

De clustergrootte wordt tijdens de indeling bepaald en kan niet worden gewijzigd zonder het volume opnieuw te formatteren. Gebruik de volgende opdracht om de huidige clustergrootte van een ReFS-volume te controleren:

fsutil fsinfo refsinfo <volume>

Voor volumes die automatisch door Windows zijn geformatteerd (bijvoorbeeld wanneer blokklonen standaard is ingeschakeld), gebruikt het systeem de standaardclustergrootte van 4 kB, tenzij deze expliciet anders is geconfigureerd tijdens het maken van het volume.

Beperkingen en opmerkingen

  • De bron- en doelregio's moeten beginnen en eindigen op een clustergrens.
  • De gekloonde regio moet minder dan 4 GB lang zijn.
  • De doelregio mag niet voorbij het einde van het bestand worden uitgebreid. Als de toepassing de bestemming wil uitbreiden met gekloonde gegevens, moet deze eerst SetEndOfFile aanroepen.
  • Als de bron- en doelregio's zich in hetzelfde bestand bevinden, mogen ze niet overlappen. (De toepassing kan doorgaan door de blokklonenbewerking op te splitsen in meerdere blokklonen die niet meer overlappen.)
  • De bron- en doelbestanden moeten zich op hetzelfde ReFS-volume bevinden.
  • De bron- en doelbestanden moeten dezelfde instelling integriteitsstromen hebben (dat wil gezegd: integriteitsstromen moeten zijn ingeschakeld in beide bestanden of zijn uitgeschakeld in beide bestanden).
  • Als het bronbestand sparse is, moet het doelbestand ook sparse zijn.
  • De blokklonenbewerking breekt gedeelde opportunistische vergrendelingen (ook wel bekend als Level 2 opportunistische vergrendelingen).
  • Het ReFS-volume moet zijn geformatteerd met Windows Server 2016 of hoger en als Windows Failover Clustering wordt gebruikt, moet het functionele clusterniveau Windows Server 2016 of hoger zijn op het moment van de indeling.

Voorbeeld

Stel dat we twee bestanden hebben, X en Y, waarbij elk bestand bestaat uit drie verschillende regio's. Elke bestandsregio wordt opgeslagen in een afzonderlijke regio van het volume. Het bestandssysteem slaat de kennis op waarnaar elk van deze volumeregio's wordt verwezen in één bestandsregio:

Een diagram met de status van de volumeregio's vóór het kloonproces.

Stel nu dat een toepassing een blokkloonbewerking van bestand X uitvoert, over de bestandsregio's A en B, naar bestand Y op de offset waar E zich momenteel bevindt. De volgende bestandssysteemstatus zou het resultaat zijn:

Een diagram met de status van de volumeregio's na het kloonproces.

De gegevens in regio's A en B zijn effectief gekopieerd van bestand X naar bestand Y door de VCN naar LCN-toewijzingen aan te passen binnen het ReFS-volume. De schijfgebieden ter ondersteuning van regio's A en B zijn niet gelezen, en de schijfgebieden ter ondersteuning van de oude regio's E en F zijn tijdens de bewerking ook niet overschreven.

Bestanden X en Y delen nu logische clusters op schijf. Dit wordt weerspiegeld in de verwijzingsaantallen die in de tabel worden weergegeven. Het delen resulteert in een lager verbruik van volumecapaciteit dan wanneer regio's A en B zijn gekopieerd op het onderliggend volume.

Stel dat de toepassing regio A in bestand X overschrijft. ReFS maakt een dubbele kopie van A, die we nu G zullen noemen. ReFS wijst vervolgens G toe aan bestand X en past de wijziging toe. Dit zorgt ervoor dat isolatie tussen de bestanden behouden blijft. Referentieaantallen worden op de juiste manier bijgewerkt:

Een diagram waarin de status van de volumeregio's wordt weergegeven nadat de schrijfbewerking is gewijzigd.

Nadat de schrijfbewerking is gewijzigd, wordt regio B nog steeds gedeeld op schijf. Houd er rekening mee dat als regio A groter was dan een cluster, alleen het gewijzigde cluster zou zijn gedupliceerd en het resterende gedeelte gedeeld zou blijven.

Gedrag van kopie-bij-schrijf

Het mechanisme van toewijzen bij schrijven werkt op clusterniveau, wat belangrijke implicaties heeft voor de prestaties en het ruimteverbruik.

  • Schrijfbewerkingen die kleiner zijn dan de clustergrootte: Een schrijfbewerking van elke grootte naar een gedeeld cluster (zelfs 1 byte) zorgt ervoor dat het hele cluster wordt gedupliceerd. Met de standaardgrootte van een cluster van 4 kB resulteert een schrijfactie van 1 kB naar een gedeelde regio in het kopiëren van 4 kB.
  • Schrijfbewerkingen die meerdere clusters omvatten: als een schrijfbewerking meerdere clusters omvat, worden alleen de gewijzigde clusters gedupliceerd. Met een schrijfbewerking van 8 kB met 4 KB-clusters worden bijvoorbeeld twee clusters gedupliceerd (totaal van 8 kB), terwijl dezelfde schrijfbewerking van 8 kB met 64 KB-clusters 1 cluster dupliceerd (totaal van 64 kB).
  • Grote opeenvolgende schrijfbewerkingen: Voor workloads die na het klonen vaak grote aaneengesloten regio's wijzigen, kunnen grotere clustergrootten (64 kB) de overhead verminderen door het aantal kopieerbewerkingen op schrijfbewerkingen te minimaliseren.

Deze granulariteit op clusterniveau is van toepassing op alle schrijfbewerkingen na blokklonen, inclusief scenario's waarin Windows 11 Moment 5 en hoger automatisch blokklonen uitvoeren tijdens kopieerbewerkingen.

DUPLICATE_EXTENTS_DATA

FSCTL_DUPLICATE_EXTENTS_TO_FILE