Condividi tramite

Aggiornamento della compatibilità dei dischi in formato avanzato (4K)

  • Articolo

Piattaforme

Client Windows XP, Windows Vista, Windows 7, Windows 7 SP1, Windows 8
Server Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2008 R2 SP1, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016

Descrizione

Questo articolo è una versione aggiornata dell'articolo intitolato 512 byte Emulation (512e) Disk Compatibility Update che è stato rilasciato per Windows 7 SP1 e Windows Server 2008 R2 SP1. Questo aggiornamento contiene molte nuove informazioni, alcune delle quali sono applicabili solo a Windows 8 e Windows Server 2012.

Le densità areali aumentano ogni anno, e con l'avvento recente di dischi da 3 TB, i meccanismi di correzione degli errori usati per gestire la riduzione del rapporto segnale-rumore (SNR) stanno diventando inefficienti; vale a dire, è necessario un aumento del sovraccarico per garantire che il supporto sia utilizzabile. Una delle soluzioni di settore di archiviazione per migliorare questo meccanismo di correzione degli errori consiste nell'introdurre un formato di supporto fisico diverso che include dimensioni del settore fisico maggiori. Questo nuovo formato di supporti fisici è denominato Formato avanzato. Pertanto, non è più sicuro fare ipotesi relative alle dimensioni del settore dei dispositivi di archiviazione moderni e gli sviluppatori dovranno studiare i presupposti sottostanti il codice per determinare se c'è un impatto.

Questo argomento presenta l'effetto dei dispositivi di archiviazione in formato avanzato sul software, illustra le operazioni che le app possono eseguire per supportare questo tipo di supporto e illustra l'infrastruttura introdotta da Microsoft con Windows Vista, Windows 7 e Windows 8 per consentire agli sviluppatori di supportare questi tipi di dispositivi. Mentre il materiale presentato in questo argomento fornisce linee guida per migliorare la compatibilità con i dischi di formato avanzato, le informazioni si applicano in genere a tutti i sistemi con dischi in formato avanzato che eseguono Windows Vista, Windows 7 e Windows 8.

Riepilogo delle nuove funzionalità correlate al settore di grandi dimensioni

L'elenco seguente riepiloga le nuove funzionalità offerte come parte di Windows 8 e Windows Server 2012 per migliorare l'esperienza dei clienti e degli sviluppatori con dischi di settore di grandi dimensioni. Descrizione più dettagliata per ogni elemento seguito.

  • Si basa sul supporto di Windows 7 SP1 per i dischi 4K con emulazione (512e) e offre supporto completo per i dischi con dimensioni di settore 4K senza emulazione (native 4K). Alcune app e scenari supportati includono:
    • Possibilità di installare e avviare Windows da un disco di settore 4K senza emulazione (disco nativo 4K)
    • VHD e nuovo formato di file VHDX
    • Supporto HyperV completo
    • Backup Windows
    • Supporto completo nel file system NT (NTFS)
    • Supporto completo con nuovi pool e Spazi di archiviazione (SSP)
    • Supporto completo con Windows Defender
  • Fornisce una nuova API per eseguire query sulle dimensioni del settore fisico (FileFsSectorSizeInformation):
    • Disponibile per i volumi di rete
    • Può essere rilasciato a qualsiasi handle di file
    • Disponibile per le app senza privilegi
    • Modello di utilizzo più descrittivo
  • Include l'utilità della riga di comando fsutil avanzata per eseguire query per le dimensioni del settore logico e fisico del volume con informazioni di allineamento (la versione di base dell'utilità senza informazioni di allineamento è disponibile per Windows 7 con Microsoft KB 982018 e Windows Server 2008 R2 con Microsoft KB 982018)

Introduzione ai dischi in formato avanzato (4K)

Uno dei problemi relativi all'introduzione di questa modifica nel formato multimediale è la possibilità di introdurre problemi di compatibilità con il software e l'hardware esistenti. Come soluzione di compatibilità temporanea, il settore di archiviazione sta inizialmente introducendo dischi che emulano un normale disco di settore a 512 byte, ma rendono disponibili informazioni sulle dimensioni reali del settore tramite comandi ATA e SCSI standard. A seguito di questa emulazione, ci sono, in sostanza, due dimensioni del settore:

Settore logico: unità usata per l'indirizzamento a blocchi logici per i supporti. È anche possibile considerarlo come l'unità di scrittura più piccola che l'archiviazione può accettare. Questo è l'emulazione.
Settore fisico: unità per cui le operazioni di lettura e scrittura nel dispositivo vengono completate in un'unica operazione. Questa è l'unità di scrittura atomica.
Le API di Windows più aggiornate, ad esempio IOCTL_DISK_GET_DRIVE_GEOMETRY restituiranno le dimensioni del settore logico, ma le dimensioni del settore fisico possono essere recuperate tramite il codice di controllo IOCTL_STORAGE_QUERY_PROPERTY , con le informazioni pertinenti contenute nel campo BytesPerPhysicalSector nella struttura STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR . Questo argomento viene illustrato in modo più dettagliato più avanti nell'articolo.

Tipi iniziali di supporti di settore di grandi dimensioni

Il settore di archiviazione sta rapidamente accelerando le attività di transizione a questo nuovo tipo di formato avanzato di archiviazione per i supporti con dimensioni fisiche di 4 KB. Due tipi di supporti verranno rilasciati sul mercato:

4 KB nativo: questo supporto non ha alcun livello di emulazione ed espone direttamente 4 KB come dimensioni logiche e fisiche del settore. Il problema complessivo di questo nuovo tipo di supporti è che la maggior parte delle app e dei sistemi operativi non esegue query per e allinea le operazioni di I/O alle dimensioni del settore fisico, causando un errore imprevisto di I/O.
Emulazione a 512 byte (512e): questo supporto ha un livello di emulazione come descritto nella sezione precedente ed espone 512 byte come dimensione logica del settore (simile a un disco normale oggi), ma rende disponibili le informazioni sulle dimensioni del settore fisico (4 KB). Il problema complessivo di questo nuovo tipo di supporti è che la maggior parte dei sistemi operativi e delle app non comprende l'esistenza delle dimensioni del settore fisico, che può comportare una serie di problemi, come illustrato di seguito.
Supporto generale di Windows per supporti di settore di grandi dimensioni

Questa tabella documenta i criteri di supporto microsoft ufficiali per vari media e le dimensioni del settore segnalate risultanti. Per informazioni dettagliate, vedere questo articolo della Knowledge Base.

Nomi comuni Dimensioni del settore logico segnalate Dimensioni del settore fisico segnalate Versione di Windows con supporto
Nativo a 512 byte, 512n 512 byte 512 byte Tutte le versioni di Windows
Formato avanzato, 512e, AF, emulazione a 512 byte 512 byte 4 KB Windows Vista w/ MS KB 2553708
Windows Server 2008* w/ MS KB 2553708
Windows 7 w/ MS KB 982018
Windows Server 2008 R2* w/ MS KB 982018
Tutte le versioni di Windows da Windows 7 SP1 e successive.
Tutte le versioni server di Server 2008 R2 SP1 e successive.

*Ad eccezione di Hyper-V. Vedere la sezione "Requisiti di supporto delle applicazioni per unità di settore di grandi dimensioni".
Formato advance, AF, nativo 4K, 4Kn 4 KB 4 KB Tutte le versioni di Windows da Windows 8 e successive
Tutte le versioni server di Windows Server 2012 e successive
Altro Non 4 KB o 512 byte Non 4 KB o 512 byte Non supportato

Nota

Anche se non sottolineato nella tabella precedente, Windows XP, Windows Server 2003 e Windows Server 2003 R2 non supportano supporti 512e o 4Kn. Anche se il sistema può essere avviato e in grado di funzionare in modo minimo, potrebbero esserci scenari sconosciuti di problemi di funzionalità, perdita di dati o prestazioni non ottimali. Di conseguenza, Microsoft consiglia vivamente di usare supporti 512e con Windows XP o altri prodotti basati sulla codebase di Windows XP (ad esempio Windows Home Server 1.0, Windows Server 2003, Windows Server 2003 R2, Windows XP 64 bit Edition, Windows XP Embedded, Windows Small Business Server 2003 e Windows Small Business Server 2003 R2).

Funzionamento dell'emulazione: read-modify-write (RMW)

Un supporto di archiviazione ha una determinata unità all'interno della quale è possibile modificare il supporto fisico. Ovvero, i supporti possono essere scritti o riscritti solo in unità delle dimensioni del settore fisico. Pertanto, le scritture che non vengono eseguite a questo livello di unità richiederebbero passaggi aggiuntivi, che verranno illustrati nell'esempio seguente.

In questo scenario, un'app deve aggiornare il contenuto di un record Datastor che si trova all'interno di un settore logico a 512 byte. Questo diagramma illustra i passaggi necessari per completare la scrittura del dispositivo di archiviazione:

passaggi per il completamento di una scrittura da parte di un dispositivo di archiviazione

Come illustrato in precedenza, questo processo comporta alcune operazioni del dispositivo di archiviazione che possono causare una perdita di prestazioni. Per evitare questo lavoro aggiuntivo, le app devono essere aggiornate per:

  • Query per le dimensioni del settore fisico
  • Assicurarsi che le scritture siano allineate alle dimensioni del settore fisico segnalate

Anche se inizialmente questo può sembrare solo un problema di prestazioni, può verificarsi un problema più grave. Esaminiamo questo argomento nella sezione successiva.

Resilienza: costo nascosto di lettura-modifica-scrittura

La resilienza parla della capacità di un'app di ripristinare lo stato tra le sessioni. Abbiamo visto cosa è necessario per un dispositivo di archiviazione 512e per eseguire un settore a 512 byte scrivere il ciclo Read-Modify-Write. Esaminiamo cosa accadrebbe se il processo di sovrascrittura del precedente settore fisico sui media fosse interrotto. Quali sarebbero le conseguenze?

  • Poiché la maggior parte delle unità disco rigido viene aggiornata sul posto, il settore fisico, ovvero la parte dei supporti in cui si trovava il settore fisico potrebbe essere stata danneggiata con informazioni incomplete a causa di una sovrascrittura parziale. In un altro modo, è possibile considerarlo come potenzialmente aver perso tutti e 8 i settori logici (che il settore fisico contiene logicamente).
  • Anche se la maggior parte delle app con un archivio dati è progettata con la possibilità di eseguire il ripristino da errori multimediali, la perdita di otto settori o un altro modo, la perdita di otto record di commit può potenzialmente rendere impossibile il ripristino normale dell'archivio dati. Un amministratore potrebbe dover ripristinare manualmente il database da un backup o potrebbe anche dover eseguire una lunga ricompilazione.
  • Un impatto più importante è che l'azione di un'altra app che causa un ciclo di lettura-modifica/scrittura può causare la perdita dei dati anche se l'app non è in esecuzione. Questo è semplicemente perché i dati e gli altri dati dell'app potrebbero trovarsi nello stesso settore fisico.

Tenendo presente questo aspetto, è importante che il software dell'app rivaluta eventuali presupposti presi nel codice e sia consapevole della distinzione delle dimensioni del settore logico-fisico, insieme ad alcuni scenari di clienti interessanti illustrati più avanti in questo articolo.

Fare la cosa giusta (evitando lettura-modifica-scrittura)

Anche se alcuni fornitori di archiviazione potrebbero introdurre alcuni livelli di mitigazione all'interno di determinati dispositivi di archiviazione 512e per provare a risolvere i problemi di prestazioni e resilienza del ciclo di lettura-modifica-scrittura, è possibile gestire solo molte mitigazioni in termini di carico di lavoro.While some storage vendors may be introducing some levels of mitigation within certain 512e storage devices to try to ease to ease of the performance and resiliency issues of the Read-Modify-Write cycle, there is only so much any mitigation can handle in termini di carico di lavoro. Di conseguenza, le app non devono basarsi su questa mitigazione come soluzione a lungo termine. Inoltre, non vi è alcuna garanzia che tutte le classi di dischi avranno questa mitigazione sul posto, né c'è una garanzia che la mitigazione sia ben progettata.

La soluzione a questo non è una mitigazione in unità, ma per progettare app per eseguire il set corretto di elementi per supportare questo tipo di supporto multimediale. Questa sezione illustra gli scenari comuni in cui le app possono avere problemi con dischi di settore di grandi dimensioni e suggerisce un'analisi per provare a risolvere ogni problema.

Problema 1: la partizione non è allineata a un limite di settore fisico

Quando l'amministratore/utente partiziona il disco, è possibile che la prima partizione non sia stata creata su un limite allineato. Ciò può causare la non idoneità di tutte le scritture successive ai limiti del settore fisico. A partire da Windows Vista SP1 e Windows Server 2008, la prima partizione viene posizionata ai primi 1024 KB del disco (per i dischi da 4 GB o superiore, altrimenti l'allineamento è di 64 KB) allineato a un limite di settore fisico di 4 KB. Tuttavia, dato il partizionamento predefinito in Windows XP, un'utilità di partizionamento di terze parti o un uso errato delle API di Windows, le partizioni create potrebbero non essere allineate a un limite di settore fisico. Gli sviluppatori dovranno assicurarsi che le API corrette vengano usate per garantire l'allineamento. Le API consigliate per garantire l'allineamento delle partizioni sono descritte di seguito.

Le API IVdsPack::CreateVolume e IVdsPack2::CreateVolume2 non usano il parametro di allineamento specificato quando viene creato un nuovo volume, ma usano invece il valore di allineamento predefinito per il sistema operativo (pre-Windows Vista SP1 userà 63 byte e dopo Windows Vista SP1 userà le impostazioni predefinite indicate in precedenza). Usare invece le API IVdsCreatePartitionEx::CreatePartitionEx o IVdsAdvancedDisk::CreatePartition che usano il parametro di allineamento specificato per le app che devono creare partizioni.

Il modo migliore per garantire che l'allineamento sia corretto consiste nel farlo correttamente quando si crea inizialmente la partizione. In caso contrario, l'app dovrà tenere conto dell'allineamento quando si eseguono operazioni di scrittura o inizializzazione che possono essere un processo molto complesso.

Problema 2: scritture senza buffer non allineate alle dimensioni del settore fisico

Il problema più semplice è che le scritture senza buffer non sono allineate alle dimensioni del settore fisico segnalate dei supporti di archiviazione. Le scritture memorizzate nel buffer, invece, sono allineate alle dimensioni della pagina di 4 KB, che in modo coincidente è la dimensione fisica del settore della prima generazione di supporti di settore di grandi dimensioni. Tuttavia, la maggior parte delle app con un archivio dati esegue scritture non memorizzate nel buffer e quindi dovrà assicurarsi che queste scritture vengano eseguite in unità di dimensione del settore fisico.

Alcuni esempi di scenari in cui l'I/O dell'app risultante non è idonea:

I record di commit vengono riempiti in settori da 512 byte: le app con un archivio dati hanno in genere una forma di record di commit che mantiene informazioni sulle modifiche ai metadati o mantiene la struttura dell'archivio dati. Per garantire che la perdita di un settore non influisca su più record, questo record di commit viene in genere riempito in base a una dimensione del settore. Con un disco con dimensioni del settore fisico maggiori, l'app dovrà eseguire una query per le dimensioni del settore fisico, come illustrato nella sezione precedente e assicurarsi che ogni record di commit venga riempito in base a tale dimensione. Con un disco 4K, ciò garantisce che le operazioni di I/O non vengano eseguite correttamente. Con un disco 512e, non solo questo evita il ciclo Read-Modify-Write, consente di garantire che se un settore fisico è andato perso, verrebbe perso un solo record commit.
I file di log vengono scritti in blocchi non allineati: I/O non memorizzati nel buffer vengono in genere usati durante l'aggiornamento o l'aggiunta a un file di log. Le app possono passare all'I/O memorizzato nel buffer o memorizzare internamente nel buffer gli aggiornamenti del log alle unità delle dimensioni del settore fisico per evitare operazioni di I/O non riuscite o attivare un'operazione di lettura-modifica/scrittura.
Per determinare se l'app genera problemi di I/O non memorizzati nel buffer, assicurarsi di includere il flag FILE_FLAG_NO_BUFFERING nel parametro dwFlagsAndAttributes quando si chiama la funzione CreateFile.

Inoltre, se attualmente si allineano le scritture alle dimensioni del settore, questa dimensione del settore è molto probabilmente solo la dimensione del settore logico, come la maggior parte delle API esistenti che eseguono query sulle dimensioni del settore del supporto solo per eseguire una query sull'unità di indirizzamento, ovvero le dimensioni del settore logico. Le dimensioni del settore sono le dimensioni del settore fisico, ovvero l'unità reale di atomicità. Ecco alcuni esempi di API che recuperano le dimensioni del settore logico:

  • GetDiskFreeSpace, GetDiskFreeSpaceEx
  • FileFsVolumeInformation
  • IOCTL_DISK_GET_DRIVE_GEOMETRY, IOCTL_DISK_GET_DRIVE_GEOMETRY_EX
  • IVdsDisk::GetProperties, IVdsDisk3::GetProperties2

Ecco come è possibile eseguire query sulle dimensioni del settore fisico:

Metodo preferito per Windows 8

Con Windows 8, Microsoft ha introdotto una nuova API che consente agli sviluppatori di integrare facilmente il supporto 4K all'interno delle proprie app. Questa nuova API supporta un numero ancora maggiore di scenari rispetto al metodo legacy per Windows Vista e Windows 7 illustrato di seguito. Questa API abilita questi scenari di chiamata:

  • Chiamata da un'app senza privilegi
  • Chiamata a qualsiasi handle di file valido
  • Chiamata a un handle di file in un volume remoto su SMB2
  • Modello di programmazione semplificato

L'API è sotto forma di una nuova classe di informazioni, FileFsSectorSizeInformation, con struttura associata FILE_FS_SECTOR_SIZE_INFORMATION, definita come segue:

typedef struct _FILE_FS_SECTOR_SIZE_INFORMATION {  
    ULONG LogicalBytesPerSector;  
    ULONG PhysicalBytesPerSectorForAtomicity;  
    ULONG PhysicalBytesPerSectorForPerformance;  
    ULONG FileSystemEffectivePhysicalBytesPerSectorForAtomicity;  
    ULONG Flags;  
    ULONG ByteOffsetForSectorAlignment;  
    ULONG ByteOffsetForPartitionAlignment;  
} FILE_FS_SECTOR_SIZE_INFORMATION, *PFILE_FS_SECTOR_SIZE_INFORMATION;

Metodo legacy per Windows 7 e Windows Vista

Windows Vista e Windows Server 2008 hanno introdotto API per eseguire query sulle dimensioni fisiche del settore fisico del dispositivo di archiviazione collegato per i controller di archiviazione basati su AHCI. Con Windows 7 e Windows Server 2008 R2, a partire da SP1 (o microsoft Knowledge Base 982018), questo supporto viene esteso ai controller di archiviazione basati su Storport. Per un esempio di codice che mostra come un'app può eseguire query sulle dimensioni del settore fisico del volume, vedere STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR struttura.

Anche se l'esempio di codice precedente consente di ottenere le dimensioni del settore fisico del volume, è consigliabile eseguire un controllo di integrità di base delle dimensioni del settore fisico segnalate prima di usarlo, poiché è stato osservato che alcuni driver potrebbero non restituire dati formattati correttamente:

  • Assicurarsi che le dimensioni del settore fisico segnalate siano >= le dimensioni del settore logico segnalate; in caso contrario, l'app deve usare una dimensione del settore fisico uguale alle dimensioni del settore logico segnalate
  • Assicurarsi che la dimensione del settore fisico segnalato sia una potenza di due; in caso contrario, l'app deve usare una dimensione del settore fisico uguale alle dimensioni del settore logico segnalate
  • Se le dimensioni del settore fisico sono un valore power-of-two compreso tra 512 byte e 4 KB, è consigliabile usare una dimensione del settore fisico arrotondata per difetto alle dimensioni del settore logico segnalate
  • Se la dimensione del settore fisico è un valore di potenza di due superiore a 4 KB, è consigliabile valutare la capacità dell'app di gestire questo scenario prima di usare tale valore; in caso contrario, è consigliabile usare una dimensione del settore fisico arrotondata a 4 KB

L'uso di questo IOCTL per ottenere le dimensioni del settore fisico presenta diverse limitazioni. IT:

  • Richiede privilegi elevati; se l'app non è in esecuzione con privilegi, potrebbe essere necessario scrivere un'applicazione di servizio di Windows come indicato in precedenza
  • Non supporta i volumi SMB; potrebbe anche essere necessario scrivere un'applicazione di servizio Windows per supportare l'esecuzione di query sulle dimensioni del settore fisico su questi volumi
  • Non è possibile eseguire l'emissione a qualsiasi handle di file (l'IOCTL deve essere emesso a un handle di volume)

Problema 3: formati di file basati su settori a 512 byte

Alcune app con formati di file standard (ad esempio VHD 1.0) potrebbero avere questi file hardcoded per presupporre dimensioni di settore a 512 byte. Di conseguenza, gli aggiornamenti e le scritture in questo file generano un ciclo read-modify-write nel dispositivo, che potrebbe causare problemi di prestazioni e resilienza per i clienti. Esistono tuttavia modi per consentire a un'app di fornire supporto per l'uso su questo tipo di supporto, ad esempio:

  • Usare il buffering per garantire che le scritture vengano eseguite in unità di dimensione del settore fisico
  • Implementare un elemento Read-Modify-Write interno che consente di garantire che gli aggiornamenti vengano eseguiti in unità delle dimensioni del settore fisico segnalate
  • Se possibile, pad registra in un settore fisico, in modo che la spaziatura interna venga interpretata come spazio vuoto
  • Prendere in considerazione la riprogettazione di una versione della struttura dei dati dell'app con supporto per settori più grandi

Problema 4: le dimensioni del settore fisico segnalate possono cambiare tra le sessioni

Esistono molti scenari in cui le dimensioni del settore fisico segnalate dello spazio di archiviazione sottostante che ospita datastor possono cambiare. Il più comune è quando si esegue la migrazione di Datastor a un altro volume o anche in rete. Una modifica delle dimensioni del settore fisico segnalate può essere un evento imprevisto per molte app e potenzialmente può causare la mancata inizializzazione di alcune app.

Questo non è lo scenario più semplice da supportare e viene menzionato qui come avviso. È consigliabile considerare i requisiti di mobilità dei clienti e modificare il supporto di conseguenza per garantire che i clienti non siano interessati negativamente dall'uso di supporti nativi 4K o 512e.

Come un utente può recuperare le dimensioni del settore logico e fisico per un volume

In-box con Windows è un'utilità per visualizzare le informazioni sulle dimensioni del settore per un volume. Le versioni di Windows con fsutil supportate sono:

  • Windows 8
  • Windows Server 2012
  • Windows 7 SP1 con Microsoft KB 982018
  • Windows 7 con Microsoft KB 982018
  • Windows Server 2008 R2 SP1 con Microsoft KB 982018 (v3)
  • Windows Server 2008 R2 con Microsoft KB 982018 (v3)
  • Windows Vista con microsoft KB 2553708
  • Windows Server 2008 con Microsoft KB 2553708

Per ottenere le informazioni sulle dimensioni del settore, chiamare l'utilità come segue da un prompt dei comandi con privilegi elevati:

fsutil fsinfo ntfsinfo <drive letter>

Un disco settore 4K con emulazione a 512 byte ha il campo Byte per settore impostato su 512 e il campo Byte per settore fisico impostato su 4096 come indicato di seguito:

byte per settore e per settore fisico di un disco di settore da 4k con emulazione di 512 byte

Un disco nativo 4K include i campi Byte per settore e byte per settore fisico entrambi impostati su 4096 come indicato di seguito:

byte per settore e per settore fisico di un disco nativo di 4k

Nota

Se il campo Byte Per Physical Sector (Settore fisico byte per settore fisico) viene visualizzato Non supportato, il driver di archiviazione non supporta IOCTL_STORAGE_QUERY_PROPERTY oppure si è verificato un errore durante il recupero delle informazioni.

Risorse