Aggiornamento della compatibilità dei dischi 512e (512-byte Emulation)

  • Articolo

Piattaforma

Client - Windows Vista, Windows 7, Windows 7 SP1
Server - Windows Server 2008, Windows Server 2008 R2, Windows Server 2008 R2 SP1

Impatto sulle funzionalità

Gravità - Alto
Frequenza - Alto

Descrizione

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 la riduzione del rapporto segnale-rumore (SNR) stanno diventando inefficienti nello spazio, ovvero un aumento del sovraccarico è necessario 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 una dimensione del settore fisico più grande. Questo nuovo formato multimediale fisico è denominato Formato avanzato. Pertanto, non è più sicuro effettuare 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 introduce l'effetto dei dispositivi di archiviazione in formato avanzato sul software, illustra le operazioni che le applicazioni possono fare per supportare questo tipo di supporto e illustra l'infrastruttura 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 dischi di formato avanzato, le informazioni si applicano in genere a tutti i sistemi con dischi di formato avanzato. Le versioni seguenti di Windows forniscono supporto per eseguire query sulle dimensioni del settore fisico:

  • Windows 7 con Microsoft KB 982018
  • Windows 7 SP1
  • Windows Server 2008 R2 con Microsoft KB 982018
  • Windows Server 2008 R2 SP1
  • Windows Vista con Microsoft KB 2553708
  • Windows Server 2008 con Microsoft KB 2553708

Per altre informazioni, vedere Informazioni sui criteri di supporto Microsoft per le unità di settore di grandi dimensioni in Windows.

Per altre informazioni sui dischi di formato avanzato, contattare il fornitore di archiviazione.

Dimensioni logiche e del settore fisico

Uno dei problemi relativi all'introduzione di questa modifica nel formato multimediale è la compatibilità con il software e l'hardware attualmente disponibili nel mercato. Come soluzione temporanea, il settore di archiviazione introduce inizialmente dischi che emulano un normale disco del settore a 512 byte, ma rende disponibili informazioni sulla vera dimensione del settore tramite comandi ATA e SCSI standard. A seguito di questa emulazione, esistono due dimensioni del settore:

  • Settore logico: unità usata per l'indirizzamento logico dei blocchi per il supporto. È anche possibile considerarlo come l'unità di scrittura più piccola che l'archiviazione può accettare. Si tratta dell'emulazione.

  • Settore fisico: unità per cui vengono completate le operazioni di lettura e scrittura nel dispositivo in un'unica operazione. Si tratta dell'unità di scrittura atomica.

La maggior parte delle API di Windows correnti, ad esempio IOCTL_DISK_GET_DRIVE_GEOMETRY restituirà 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 BytePerPhysicalSector nella struttura STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR . Questa operazione viene illustrata più dettagliatamente più avanti nell'articolo.

Tipi iniziali di supporti di settore di grandi dimensioni

Il settore di archiviazione sta rapidamente accelerando gli sforzi per passare a questo nuovo tipo di formato avanzato di archiviazione per i supporti con dimensioni del settore fisico di 4 KB. Due tipi di supporti verranno rilasciati sul mercato:

  • 4 KB Native: questo supporto non ha alcun livello di emulazione ed espone direttamente 4 KB come dimensione logica e fisica del settore. Questo supporto attualmente non è supportato da Windows e dalla maggior parte degli altri sistemi operativi. Tuttavia, Microsoft sta conducendo un'indagine sulla fattibilità di supportare questo tipo di supporto in una versione futura di Windows e emetterà un articolo di Knowledge Base quando appropriato.
  • 512 byte Emulation (512e): questo supporto ha un livello di emulazione come illustrato nella sezione precedente ed espone 512 byte come dimensione del settore logico (simile a un disco normale oggi), ma rende disponibili le informazioni sul settore fisico (4 KB). Questo è ciò che diversi fornitori di archiviazione stanno attualmente introducendo al mercato. Questo problema complessivo con questo nuovo tipo di supporti è che la maggior parte delle applicazioni e dei sistemi operativi non comprende l'esistenza della dimensione del settore fisico, che può comportare un numero di problemi come illustrato di seguito.

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à delle dimensioni del settore fisico. Pertanto, le scritture che non vengono eseguite a questo livello di unità richiedono passaggi aggiuntivi, che verranno illustrati nell'esempio seguente.

In questo scenario, un'applicazione deve aggiornare il contenuto di un record Datastor situato all'interno di un settore logico a 512 byte. Il diagramma seguente illustra i passaggi necessari per il dispositivo di archiviazione per completare la scrittura:

passaggi necessari per aggiornare il record datastor all'interno di un settore logico a 512 byte

Come illustrato in precedenza, questo processo comporta un lavoro da parte del dispositivo di archiviazione che può causare una perdita di prestazioni. Per evitare questo lavoro aggiuntivo, le applicazioni devono essere aggiornate per eseguire le operazioni seguenti:

  • Eseguire una query sulle dimensioni del settore fisico.
  • Assicurarsi che le scritture siano allineate a quella dimensione del settore fisico segnalata.

Impatto sulla resilienza di Read-Modify-Write

La resilienza parla della capacità di un'applicazione di ripristinare lo stato tra le sessioni. Abbiamo visto cosa è necessario per un dispositivo di archiviazione 512e per eseguire una scrittura di 512 byte- il ciclo Read-Modify-Write. Esaminiamo cosa succederebbe se il processo di sovrascrittura del settore fisico precedente sul supporto è stato 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 trova il settore fisico, potrebbe essere stata danneggiata con informazioni incomplete a causa di una sovrascrittura parziale. Mettere in un altro modo, è possibile pensarlo come potenzialmente aver perso tutti i 8 settori logici (che il settore fisico contiene logicamente).

  • Anche se la maggior parte delle applicazioni con un archivio dati è progettata con la possibilità di recuperare 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 in modo corretto dell'archivio dati. Un amministratore potrebbe dover ripristinare manualmente il database da un backup o potrebbe anche dover eseguire una ricompilazione lunga.

  • Un impatto più importante è che l'atto di un'altra applicazione che causa un ciclo di lettura-modifica-scrittura può potenzialmente causare la perdita dei dati, anche se l'applicazione non è in esecuzione! Questo è semplicemente perché i dati e gli altri dati dell'applicazione potrebbero trovarsi all'interno dello stesso settore fisico.

Con questo aspetto, è importante che il software dell'applicazione 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.

Questo problema è più probabile che si verifichi se l'applicazione si basa su un archivio dati della struttura di log.

Evitare la lettura-modifica-scrittura

Anche se alcuni fornitori di archiviazione possono introdurre alcuni livelli di mitigazione all'interno di determinati dispositivi di archiviazione 512e per provare a semplificare le prestazioni e i problemi di resilienza del ciclo di lettura-modifica-scrittura, esiste solo così tanto che qualsiasi mitigazione può gestire in termini di carico di lavoro. Di conseguenza, le applicazioni non devono basarsi su questa mitigazione come soluzione a lungo termine.

La soluzione a questa non è mitigazione in unità, ma per avere applicazioni fare il set corretto di operazioni per evitare il ciclo Read-Modify-Write. Questa sezione illustra gli scenari comuni in cui le applicazioni potrebbero avere problemi con dischi di settore di grandi dimensioni e suggerisce un percorso di indagine per provare e risolvere ogni problema.

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

Quando l'amministratore/utente partiziona il disco, la prima partizione potrebbe non essere stata creata su un limite allineato. Ciò può causare che tutte le scritture successive diventino non idonee 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 più grandi, altrimenti l'allineamento è 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 utilizzo 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 e utilizzano invece il valore di allineamento predefinito per il sistema operativo (Pre-Windows Vista SP1 userà 63 byte e post Windows Vista SP1 userà le impostazioni predefinite indicate sopra). È quindi consigliabile che le applicazioni che devono creare partizioni usino invece le API IVdsCreatePartitionEx::CreatePartitionEx o IVdsAdvancedDisk::CreatePartition , che usano il parametro di allineamento specificato.

Il modo migliore per garantire che l'allineamento sia corretto consiste nel farlo correttamente quando si crea inizialmente la partizione. In caso contrario, l'applicazione dovrà tenere conto dell'allineamento durante l'esecuzione di scritture o inizializzazione, che può essere una questione molto complessa. A partire da Windows Vista SP1, questo non è in genere un problema; tuttavia, le versioni precedenti di Windows possono creare partizioni non idonee che possono potenzialmente causare problemi di prestazioni con alcuni dischi di formato avanzato.

Problema 2: Scritture non allineate alle dimensioni del settore fisico

Il problema di base è che le scritture non memorizzate non sono allineate alle dimensioni del settore fisico segnalate dei supporti di archiviazione, che attivano una scrittura di lettura-modifica nell'unità che può causare problemi di prestazioni. Le scritture memorizzate nel buffer, invece, sono allineate alle dimensioni della pagina - 4 KB - che in modo coincidente è la dimensione fisica del settore fisico della prima generazione di supporti di settore di grandi dimensioni. Tuttavia, la maggior parte delle applicazioni con un archivio dati esegue scritture non memorizzate e pertanto dovrà assicurarsi che queste scritture vengano eseguite in unità delle dimensioni del settore fisico.

Per determinare se i problemi dell'applicazione non vengono inseriti in I/O, verificare di includere il flag di 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 è più probabile solo la dimensione del settore logico, come la maggior parte delle API esistenti che esegue una query sulle dimensioni del settore del supporto in realtà esegue una query sull'unità di indirizzamento, ovvero la dimensione del settore logico . La dimensione del settore è la dimensione fisica del settore, ovvero l'unità reale dell'atomicità. Alcuni esempi di API che recuperano le dimensioni del settore logico sono:

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

Come eseguire query sulle dimensioni del settore fisico

Microsoft ha fornito un esempio di codice su MSDN in dettaglio su come un'applicazione può eseguire query sulle dimensioni del settore fisico del volume. L'esempio di codice si trova in https://msdn.microsoft.com/library/ff800831.aspx.

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 sulle 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'applicazione 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'applicazione 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'applicazione 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:

  • Richiede privilegi elevati. Se l'applicazione 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).

  • Supportato solo nelle versioni di Windows elencate all'inizio di questo articolo.

I record di commit vengono riempiti in settori a 512 byte

Le applicazioni con un archivio dati hanno in genere una forma di record di commit che gestisce 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'applicazione 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. Non solo questo evita il ciclo Read-Modify-Write, ma consente di garantire che nel caso in cui un settore fisico venga perso, solo un record commit andrebbe perso.

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. Esistono diversi modi per garantire che questi aggiornamenti siano allineati correttamente:

  • Aggiornamento interno del log del buffer alle dimensioni del settore fisico segnalate dei supporti operativi e scrittura del log dei problemi solo quando un'unità di settore fisico è piena
  • Usare le I/O memorizzate nel buffer

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

Alcune applicazioni con formati di file standard (ad esempio VHD 1.0) possono avere questi file hardcoded per presupporre una dimensione 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 consentire a un'applicazione di fornire supporto 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 nuova versione della struttura dei dati dell'applicazione 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 applicazioni e può potenzialmente causare la mancata inizializzazione di alcune applicazioni.

Questo non è lo scenario più semplice da supportare e viene indicato qui come avviso. È consigliabile prendere in considerazione i requisiti di mobilità dei clienti e modificare il supporto di conseguenza per garantire che i clienti non siano interessati negativamente usando 512e supporti.

Supporto nativo di 4 KB

Il supporto di emulazione a 512 byte è un passaggio transitorio tra supporti nativi a 512 byte e 4 KB nativi e si prevede di vedere 4 supporti nativi kb rilasciati subito dopo la disponibilità di 512e. Ci sono diverse implicazioni importanti con questi media che devono essere annotati:

  • Le dimensioni del settore logico e fisico sono entrambe di 4 KB
  • Poiché non è presente alcun livello di emulazione, le scritture non allineate non saranno riuscite dalla risorsa di archiviazione
  • Nessun riscontro della resilienza nascosta: le applicazioni funzionano o non funzionano

Anche se Microsoft sta attualmente esaminando il supporto per questi tipi di supporti in una versione futura di Windows e emetterà un articolo della Knowledge Base, se appropriato, gli sviluppatori di applicazioni dovrebbero prendere in considerazione la possibilità di fornire il supporto per questi tipi di supporti.

Chiusura

In questo articolo sono stati illustrati gli effetti che i supporti di settore di grandi dimensioni introducono con molti scenari di distribuzione comuni. Abbiamo visto l'impatto sulle prestazioni e sulla resilienza di Read-Modify-Write, alcuni degli scenari interessanti che questo supporto può introdurre e il set di problemi che possono causare potenzialmente con il software, che in definitiva influisce sull'utente finale. Il settore di archiviazione sta rapidamente passando ai supporti con dimensioni del settore più grandi e molto presto i clienti non potranno acquistare dischi con dimensioni tradizionali del settore a 512 byte.

Si tratta di un documento vivente ed è destinato agli sviluppatori per comprendere questa transizione. È consigliabile avviare una conversazione con le rispettive organizzazioni, con clienti, professionisti IT e fornitori di hardware per parlare della transizione del settore di grandi dimensioni e di come influisce sugli scenari importanti per l'utente.