Condividi tramite

Aggiornamento della compatibilità del disco in formato avanzato (4K)

  • Articolo

Piattaforme

Clienti 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 3 TB di dischi, i meccanismi di correzione degli errori usati per gestire il rapporto segnale-rumore (SNR) decrescente stanno diventando inefficienti nello spazio; vale a dire, è necessario un aumento del sovraccarico per garantire che il supporto sia utilizzabile. Una delle soluzioni del 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 più grandi. Questo nuovo formato multimediale fisico è 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 si verifica 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. Sebbene il materiale presentato in questo argomento fornisca linee guida per migliorare la compatibilità con i dischi in 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. Per ogni elemento seguire una descrizione più dettagliata.

  • Si basa sul supporto di Windows 7 SP1 per i dischi 4K con emulazione (512e) e offre il supporto completo della posta in arrivo per i dischi con dimensioni del settore 4K senza emulazione (4K Native). Alcune app e scenari supportati includono:
    • Possibilità di installare Windows da e avviare da un disco di settore 4K senza emulazione (disco nativo 4K)
    • VHD e nuovo formato di file VHDX
    • Supporto completo di HyperV
    • Backup di 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 introduce inizialmente dischi che emulano un normale disco del 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à utilizzata per l'indirizzamento di blocchi logici per il supporto. È anche possibile considerarlo come l'unità di scrittura più piccola che l'archiviazione può accettare. Questa è l'emulazione.
Settore fisico: Unità per cui le operazioni di lettura e scrittura nel dispositivo vengono completate in una singola operazione. Si tratta dell'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 descritto in modo più dettagliato più avanti nell'articolo.

Tipi iniziali di supporti di settore di grandi dimensioni

L'industria di archiviazione sta rapidamente impegnandosi a passare a questo nuovo tipo di formato avanzato di archiviazione per i supporti con dimensioni fisiche di 4 KB. Due tipi di supporti saranno rilasciati sul mercato:

4 KB nativo: Questo supporto non ha un livello di emulazione e espone direttamente 4 KB come dimensione del settore logico e fisico. Il problema complessivo di questo nuovo tipo di supporto è 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 del settore logico (simile a un normale disco oggi), ma rende disponibili le informazioni sulle dimensioni del settore fisico (4 KB). Il problema generale di questo nuovo tipo di supporti è che la maggior parte dei sistemi operativi e delle app non capisce 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 supporti 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 versioni 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 di avanzamento, AF, nativo 4K, 4Kn 4 KB 4 KB Tutte le versioni di Windows da Windows 8 e versioni successive
Tutte le versioni del server da Windows Server 2012 e versioni 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 al minimo, potrebbero esserci scenari sconosciuti di problemi di funzionalità, perdita di dati o prestazioni non ottimali. Pertanto, Microsoft ha fortemente cautela rispetto all'uso di 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 a 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, in unità di dimensione del settore fisico. Di conseguenza, le scritture che non vengono eseguite a questo livello di unità richiedono 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 il dispositivo di archiviazione per completare la scrittura:

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 comportare 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 potrebbe 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 indica la capacità di un'app di ripristinare lo stato tra le sessioni. Abbiamo visto cosa è necessario per un dispositivo di archiviazione da 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, 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 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 all'interno dello stesso settore fisico.

Tenendo presente questo aspetto, è importante che il software dell'app rivaluta le ipotesi prese 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 possono introdurre alcuni livelli di mitigazione all'interno di determinati dispositivi di archiviazione 512e per cercare di semplificare i problemi di prestazioni e resilienza del ciclo lettura-modifica-scrittura, è possibile gestire solo qualsiasi mitigazione in termini di carico di lavoro. Di conseguenza, le app non devono basarsi su questa mitigazione come soluzione a lungo termine. Inoltre, non esiste 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 operazioni per supportare questo tipo di supporto. In questa sezione vengono illustrati gli scenari comuni in cui le app potrebbero avere problemi con dischi di settore di grandi dimensioni e suggerisce un percorso di indagine per provare a risolvere ogni problema.

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

Quando l'amministratore o l'utente partiziona il disco, è possibile che la prima partizione non sia stata creata su un limite allineato. In questo modo tutte le scritture successive diventano non allineate ai limiti del settore fisico. A partire da Windows Vista SP1 e Windows Server 2008, la prima partizione viene posizionata al primo 1024 KB del disco (per i dischi 4 GB o superiori, in caso contrario 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 l'utilizzo non corretto delle API di Windows, le partizioni create potrebbero non essere allineate a un limite di settore fisico. Gli sviluppatori dovranno assicurarsi che vengano usate le API corrette 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 usare 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 durante la creazione iniziale della 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 non memorizzate nel 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 del supporto di archiviazione. Le scritture memorizzate nel buffer, d'altra parte, sono allineate alle dimensioni della pagina 4 KB, che in modo casuale è 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 senza 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 è allineata:

I record di commit vengono riempiti in settori a 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 di 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 fino 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, ma 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: L'I/O non memorizzato viene in genere usato durante l'aggiornamento o l'aggiunta a un file di log. Le app possono passare all'I/O memorizzato nel buffer oppure 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 è probabilmente solo la dimensione del settore logico, come la maggior parte delle API esistenti che eseguono query per le dimensioni del settore del supporto è sufficiente eseguire una query sull'unità di indirizzamento, ovvero la dimensione del settore logico. La dimensione del settore è la dimensione del settore fisico, che è l'unità reale dell'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 una query per le 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 nelle 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 info, 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. Microsoft ha fornito un esempio di codice in MSDN che illustra in dettaglio come un'app può eseguire query sulle dimensioni del settore fisico del volume.

Anche se l'esempio di codice precedente consente di ottenere le dimensioni fisiche del settore del volume, è consigliabile eseguire un controllo di integrità di base delle dimensioni del settore fisico segnalate prima di usarlo, come si è notato 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 la dimensione del settore fisico è un valore power-of-two compreso tra 512 byte e 4 KB, è consigliabile usare una dimensione fisica del settore arrotondata per difetto alle dimensioni del settore logico segnalate
  • Se la dimensione del settore fisico è un valore power-of-two maggiore di 4 KB, è necessario 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 per difetto 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 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 un 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) possono avere questi file hardcoded per presupporre dimensioni del 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. Tuttavia, esistono modi per fornire supporto per un'app per operare 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
  • Valutare la possibilità di riprogettare 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 dell'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 indicato 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 usando supporti nativi 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 indicato di seguito 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 4k

Nota

Se il campo Byte per settore fisico visualizza Non supportato, il driver di archiviazione non supporta IOCTL_STORAGE_QUERY_PROPERTY o si è verificato un errore nel recupero delle informazioni.

Risorse