Not
Åtkomst till denna sida kräver auktorisation. Du kan prova att logga in eller byta katalog.
Åtkomst till denna sida kräver auktorisation. Du kan prova att byta katalog.
ODX (Offloaded Data Transfer) är en funktion som påskyndar serverkopierings- och flyttåtgärder. Den här funktionen är tillgänglig från och med Windows Server 2012 och stöds på NTFS-volymer. Den här sidan beskriver ODX ur ett filsystem- och minifilterperspektiv. Information om lagringsenheter finns i Windows Storage Offloaded Data Transfers.
Överföring av data mellan datorer eller på samma dator är en frekvent filsystemaktivitet. Att använda standardfunktionerna ReadFile och WriteFile fungerar bra ur funktionssynpunkt, men det innebär tung dataflytt genom alla nivåer i systemet och potentiellt över ett nätverk. Den här komplexiteten kan påverka tillgängligheten för de system som ingår i överföringen och nätverket som ansluter systemen. De avancerade funktionerna som är tillgängliga med många lagringsundersystem ger ett effektivare sätt att utföra den tunga uppgiften för dataflytt.
Program kan dra nytta av dessa funktioner för att avlasta processen för dataflytt till lagringsundersystemet. Filsystemfilter kan vanligtvis övervaka dessa åtgärder genom att fånga upp läs- och skrivbegäranden till en volym. Fler åtgärder krävs för att filter ska vara medvetna om ODX.
Vanliga dataöverföringar
Det är enklare att flytta runt data i ett programscenario i dag. Det handlar om att läsa in data i det lokala minnet och sedan skriva tillbaka dem till en ny plats. Följande diagram illustrerar det här scenariot.
Det här scenariot omfattar kopiering av en fil mellan två platser på två olika filservrar, var och en med en egen virtuell disk som exponeras via en Intelligent Storage Array (ISA). Det initierande systemet måste först läsa data från den virtuella källdisken till en lokal buffert. Den paketerar och överför sedan data via vissa transporter och protokoll (t.ex. SMB över 1 GbE) till det andra systemet. Det andra systemet tar sedan emot data och matar ut dem till en lokal buffert. Sedan skriver målsystemet data till den virtuella måldisken. I det här scenariot beskrivs en typisk läs-/skrivmetod för dataöverföring som utförs flera gånger av många olika program varje dag.
Även om standardläsningar och skrivningar fungerar bra i de flesta scenarier kan de data som ska kopieras finnas på virtuella diskar som hanteras av samma intelligenta lagringsmatris. Den här situationen innebär att data flyttas från matrisen, till en server, över en nätverkstransport, till en annan server och tillbaka till samma matris igen. Att flytta data inom en server och över en nätverkstransport kan avsevärt påverka tillgängligheten för dessa system. Dessutom begränsas dataöverföringens kapacitet av nätverkets kapacitet och tillgänglighet.
Avlastade dataöverföringar (ODX)
Avlasta dataöverföringen
Två FSCTL:er introducerades i Windows 8 som underlättar en metod för att avlasta dataöverföringen. Den här avlastningen förskjuter bitflytten från servrar till bitrörelser som sker intelligent i lagringsundersystemen. Det bästa sättet att visualisera kommandosemantiken är att tänka på dem som liknande en obufferad läsning och en obufferad skrivning.
-
Den här kontrollbegäran tar en förskjutning i filen som ska läsas och en önskad längd i FSCTL_OFFLOAD_READ_INPUT-strukturen. Om det stöds tar lagringsundersystemet som är värd för filen emot det associerade offload-läskommandot för lagring. Den genererar sedan en token, vilket är en logisk representation av de data som ska läsas vid tidpunkten för avläsningskommandot. Den här tokensträngen returneras till anroparen i FSCTL_OFFLOAD_READ_OUTPUT struktur.
-
Den här kontrollbegäran tar en förskjutning i filen som ska skrivas till, den önskade längden på skrivning och den token som är en logisk representation av de data som ska skrivas. Om det stöds tar lagringsundersystemet som är värd för filen som ska skrivas emot det associerade avlastningslagringskommandot för avlastning. Den försöker först identifiera den angivna token och utför sedan skrivåtgärden om möjligt. Skrivåtgärden slutförs under Windows och därför ser komponenter i filsystemet och lagringsstackarna inte dataflytten. När dataflytten är klar returneras antalet skrivna byte till anroparen.
I likhet med det första diagrammet visar följande diagram en enkel filkopia mellan två virtuella diskar på två olika servrar.
Men i stället för att göra vanliga läsningar och skrivningar avlastar vi det tunga jobbet med att flytta bitar till lagringssystemet. Det första systemet utfärdar avlastningsläsningsåtgärden och begär att matrisen ska generera en token som representerar en punkt-i-tid-vy över de data som ska läsas inom regionen för den första virtuella disken. Det första systemet överför sedan token till det andra systemet, vilket i sin tur utfärdar en avlastningsskrivningsåtgärd till den andra virtuella disken med token. Matrisen tolkar sedan token och försöker utföra dataflytten mellan de virtuella diskarna. Den faktiska dataöverföringen sker inom den intelligenta lagringsmatrisen och inte mellan de två värdarna. Den här designen förbättrar avsevärt tillgängligheten för de två systemen samtidigt som nätverkstrafiken mellan systemen i stort sett elimineras.
Integrering med kopieringsmotorn
Huvudkopieringsmotorn i Windows används av CopyFile och relaterade funktioner. Från och med Windows 8 försöker kopieringsmotorn transparent använda ODX före den traditionella sökvägen för kopieringsfilens kod. Kopierings-API:erna används av de flesta program, verktyg och gränssnittet. Dessa anropare kan använda ODX-funktioner som standard med liten, om någon, kodändring eller användarintervention.
Följande steg sammanfattar hur kopieringsmotorn försöker använda en ODX:
- Kopieringsmotorn utfärdar ett FSCTL_OFFLOAD_READ på källfilen för att erhålla en lästoken.
- Om det uppstod ett fel vid hämtning av lästoken återgår kopieringsmotorn till traditionella läsningar och skrivningar (den traditionella sökvägen för kopieringsfilens kod). Om felet indikerar att källvolymen inte stöder avlastning markerar kopieringsmotorn även volymen i en cache per process. Kopieringsmotorn provar inte avlastning längre för volymerna i cacheminnet per process.
- Om en token har hämtats försöker kopieringsmotorn utfärda FSCTL_OFFLOAD_WRITE kommandon för målfilen i stora bitar tills alla data som representeras logiskt av token skrivs av.
- Eventuella fel vid avlastning av läs- eller skrivoperationer resulterar i att kopieringsmotorn återgår till den traditionella läs-/skrivkodsökvägen. Den här återgången börjar där avlastningsvägen slutade (där läsningen eller skrivningen förkortades). Kopieringsmotorn uppdaterar samma cache per process så att den inte provar avlastning på dessa volymer om något av följande villkor är sant. Den här cachen per process återställs med jämna mellanrum.
- Felet anger att målvolymen inte stöder avlastning.
- Källvolymen kan inte nå målvolymen.
Följande funktioner stöder ODX:ar:
- CopyFile
- CopyFileEx
- MoveFile
- MoveFileEx
- CopyFile2
Följande funktioner stöder inte ODX:
- CopyFileTransacted
- MoveFileTransacted
Scenarier för avlastning av dataöverföring som stöds
Stöd för avlastningsåtgärderna finns i Hyper-V lagringsstacken och i Windows SMB-filservern. Om den fysiska lagringen för säkerhetskopiering stöder ODX-åtgärder kan anropare utfärda FSCTL_OFFLOAD_READ och FSCTL_OFFLOAD_WRITE till filer som finns på virtuella hårddiskar eller på fjärrfilresurser, oavsett om de är inifrån en virtuell dator eller på fysisk maskinvara. Följande diagram illustrerar de mest grundläggande käll- och målmålen för ODX:er.
Opt-in-modell för filsystemfilter och effekt på program
Från och med Windows 8 tillåter Filterhanteraren ett filter att ange avlastningskapacitet som en stödd funktion. Filsystemfilter som är kopplade till en volym kan gemensamt avgöra om en viss avläst åtgärd stöds. Om den inte stöds misslyckas åtgärden med en lämplig felkod.
Ett filter måste ange att det stöder FSCTL_OFFLOAD_READ och FSCTL_OFFLOAD_WRITE via ett register-DWORD-värde med namnet SupportedFeatures, som finns i drivrutinstjänstdefinitionen i registret vid HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\filterdrivrutinsnamn\. Det här värdet innehåller bitfält där bitarna avgör vilka funktioner som har valts och som ska anges under filterinstallationen.
För närvarande är de definierade bitarna:
| Flagga | Innebörd |
|---|---|
| SUPPORTED_FS_FEATURES_OFFLOAD_READ 0x00000001 | Filter stöder FSCTL_OFFLOAD_READ |
| SUPPORTED_FS_FEATURES_OFFLOAD_WRITE 0x00000002 | Filter stöder FSCTL_OFFLOAD_WRITE |
Filterregistreringsmodellen kan aktiveras eller inaktiveras baserat på värdet som finns i HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\FilterSupportedFeaturesMode registernyckeln, som har följande värden:
| Värde för FilterSupportedFeaturesMode | Innebörd |
|---|---|
| 0 (standardinställning) | Utför normal opt-in-bearbetning. |
| 1 | Gå aldrig med (vilket motsvarar att ställa in SupportedFeatures till 0 för alla tillkopplade filter) |
Testa
Om du vill kontrollera ett filters funktioner som stöds i stacken använder du fltmc-verktyget. Kör fltmc-instanser – v [volym]: som en upphöjd användare och kontrollera kolumnen SprtFtrs :
- Om SprtFtrs-värdet är 0x00 innebär det att filtret blockerar avlastning på den här volymen. Om SprtFtrs är inställt på 0x03 stöds båda avlastningsåtgärderna.
Kontrollera funktionsstöd i IRP-bearbetning
Som en del av IRP-bearbetningen hämtar FsRtlGetSupportedFeatures-rutinen det aggregerade tillståndet SupportedFeatures för alla filter som är kopplade till den angivna volymstacken. Komponenter som I/O Manager och SRV (SMB) anropar den här rutinen för att verifiera tillståndet SupportedFeatures för alla filter i stacken. Komponenter som rullar sina egna avlastnings-IRP:er bör anropa den här funktionen för att verifiera opt-in-stöd för den åtgärden.
Överväganden för filterdrivrutiner
ODX är ett sätt att flytta runt data i datacentret. På grund av integreringen av avlastningslogik i kärnkopieringsmotorn har många program som standard möjlighet att utföra avlastad dataflytt utan att uttryckligen välja att delta. Därför måste filterutvecklare förstå hur dessa åtgärder påverkar filter. Att inte förstå dessa åtgärder helt eller inte utvärdera ändringen av dataflödet kan potentiellt resultera i scenarier där data kan bli inkonsekventa eller skadade. I följande lista sammanfattas en lista med åtgärdspunkter för filterutvecklare att notera för avlastning.
- Förstå det här dataflödet, effekten på filtret och filtrets förmåga att stödja dessa avlastade åtgärder.
- Uppdatera filterinstallationsprogrammet för att lägga till ett REG_DWORD värde för SupportedFeatures i undernyckeln HKLM\System\CurrentControlSet\Services\[filter]. Initiera den för att ange avlastningsfunktion.
- För filter som vill agera vid avlastningsåtgärder uppdaterar du registreringen till IRP_MJ_FILE_SYSTEM_CONTROL för att hantera FSCTL_OFFLOAD_READ och FSCTL_OFFLOAD_WRITE.
- För filter som behöver blockera överflyttade operationer, returnera statuskoden STATUS_NOT_SUPPORTED från filtret. Förlita dig inte på registervärdet för att framtvinga blockering av avlastningsåtgärder eftersom slutanvändare kan ändra det. Ett filter bör uttryckligen tillåta eller inte tillåta avlastningsåtgärder.
Kopiera token
Med avlastade åtgärder ser I/O-stacken inte fildata. I stället ses fildata som en 512 byte-token som är den logiska proxyn för data. Den här token är antingen:
- En ogenomskinlig och unik sträng i ett leverantörsspecifikt format som genereras av lagringsundersystemet.
- En välkänd typ som representerar ett datamönster (till exempel ett dataområde som logiskt motsvarar noll).
Ändringar av proxytokens data resulterar i att token ogiltigförklaras eller att lagringsundersystemet bevarar ursprungliga data på vissa leverantörsspecifika sätt, till exempel via en mekanism för ögonblicksbilder. Efterföljande läsbegäranden för avlastning till ett angivet intervall i en fil resulterar i unika token.
Det finns klasser av token som representerar ett datamönster som är väldefinierat. Den vanligaste välkända token är Nolltoken, vilket motsvarar noll. När en token definieras som en välkänd token anges TokenType-medlemmen i STORAGE_OFFLOAD_TOKEN-strukturen till STORAGE_OFFLOAD_TOKEN_TYPE_WELL_KNOWN. När det här fältet har angetts avgör WellKnownPattern-medlemmen vilket datamönster token är.
- När fältet WellKnownPattern är inställt på STORAGE_OFFLOAD_PATTERN_ZERO eller STORAGE_OFFLOAD_PATTERN_ZERO_WITH_PROTECTION_INFORMATION anger det nolltoken. När den här token returneras av en FSCTL_OFFLOAD_READ åtgärd anger den att data som finns inom önskat filintervall logiskt motsvarar noll. När den här token tillhandahålls till en FSCTL_OFFLOAD_WRITE åtgärd anger den att det önskade intervallet för filen som ska skrivas till ska nollställas logiskt.
- Förutom nolltoken finns det för närvarande inga andra välkända tokenmönster definierade. Vi rekommenderar inte att användarna definierar sina egna välkända tokenmönster.
Avkortning
Det underliggande lagringsundersystemet som Windows kommunicerar med kan bearbeta mindre data som önskades i en avlastningsåtgärd. Denna företeelse kallas trunkering. När avlastningen läses in representerar den returnerade token ett intervall av data som är mindre än de data som begärdes. TransferLength-medlemmen i FSCTL_OFFLOAD_READ_OUTPUT-strukturen används för att ange det här värdet, vilket är ett byteantal från början av filintervallet som ska läsas. För avlastningsskrivning anger en trunkering att mindre data skrevs än vad som var önskat. LengthWritten-medlemmen i FSCTL_OFFLOAD_WRITE_OUTPUT struktur anger det här värdet, vilket är ett byteantal från början av filintervallet som ska skrivas. Fel vid kommandobearbetning eller begränsningar i stacken för stora intervall leder till avkortning.
Det finns två scenarier där NTFS trunkerar intervallet för att utföra offload-läse- eller skrivoperationer.
Kopieringsintervallet trunkeras till VDL (Valid Data Length) om VDL ligger före slutet av filen (EOF). Den här åtgärden förutsätter att VDL är justerat till en logisk sektorgräns, annars se scenariet.
Under en FSCTL_OFFLOAD_READ-åtgärd anges flaggan OFFLOAD_READ_FLAG_ALL_ZERO_BEYOND_CURRENT_RANGE i FSCTL_OFFLOAD_READ_OUTPUT struktur som anger att resten av filen innehåller nollor och att TransferLength-medlemmen trunkeras till VDL.
Precis som scenario 1, men när VDL inte är justerat till en logisk sektorgräns, trunkerar NTFS det önskade intervallet till nästa logiska sektorgräns.
Begränsningar
- Avlastningsåtgärder stöds endast på NTFS-volymer.
- Avlastningsåtgärder stöds via fjärrfilservrar om följande villkor båda är sanna:
- Fjärrresursen är en NTFS-volym.
- Servern kör Windows Server 2012 eller senare versioner (förutsatt att fjärrstacken också stöder avlastningsåtgärder).
- NTFS stöder inte avlastning av FSCTL:er som utförs på filer som krypterats med BitLocker- eller NTFS-kryptering (EFS), deduplicerade filer, komprimerade filer, residensfiler, glesa filer eller filer som deltar i TxF-transaktioner.
- NTFS stöder inte avlastning av FSCTLs som utförs på filer i en volsnap-snapshot.
- NTFS misslyckas med avlastningen av FSCTL om något av följande villkor är sant. Den här metoden följer samma semantik som icke-cachekopplad I/O.
- Det önskade filintervallet är inte justerat till den logiska sektorstorleken på källenheten.
- Det önskade filintervallet är inte justerat till den logiska sektorstorleken på målenheten.
- Målfilen måste förallokeras (SetEndOfFile och inte SetAllocation) innan FSCTL_OFFLOAD_WRITE.
- När NTFS bearbetar avlastningsläsningar och skrivningar anropas först CcCoherencyFlushAndPurgeCache för att checka in ändrade data i systemcachen. Den här åtgärden är samma semantiska som icke-cachekopplad I/O.