Condividi tramite

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

  • Articolo

Piattaforma

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

Impatto sulle funzionalità

Gravità - Alta
Frequenza - Alta

Descrizione

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, ovvero una maggiore quantità di overhead è necessaria 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 possono essere eseguite dalle applicazioni 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 i dischi in formato avanzato, le informazioni si applicano in genere a tutti i sistemi con dischi in formato avanzato. Le versioni seguenti di Windows forniscono supporto per l'esecuzione di 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 altri dettagli, vedere Informazioni sui criteri di supporto Microsoft per le unità di settore di grandi dimensioni in Windows.

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

Dimensioni logiche e del settore fisico

Una delle preoccupazioni nell'introdurre questa modifica nel formato multimediale è la compatibilità con il software e l'hardware attualmente disponibili sul mercato. Come soluzione 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. In seguito a questa emulazione, esistono 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.

La maggior parte delle API 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 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 gli sforzi per passare 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 Native: questo supporto non ha alcun livello di emulazione ed espone direttamente 4 KB come dimensioni logiche e fisiche del settore. Questo supporto non è attualmente supportato da Windows e dalla maggior parte degli altri sistemi operativi. Tuttavia, Microsoft sta conducendo un'indagine sulla fattibilità del supporto di questo tipo di supporto in una versione futura di Windows e genererà un articolo della Knowledge Base quando appropriato.
  • 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 fisiche del settore (4 KB). Questo è ciò che diversi fornitori di archiviazione stanno introducendo sul mercato. Questo problema complessivo con questo nuovo tipo di supporti è che la maggior parte dei sistemi operativi e delle applicazioni non comprende l'esistenza delle dimensioni del settore fisico, che può comportare una serie 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 solo in unità delle dimensioni del settore fisico. Pertanto, le scritture non eseguite a questo livello di unità richiederebbero passaggi aggiuntivi, che verranno illustrati nell'esempio seguente.

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

passaggi necessari per aggiornare il record datastor in un settore logico a 512 byte

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, è necessario aggiornare le applicazioni per eseguire le operazioni seguenti:

  • Eseguire una query sulle dimensioni del settore fisico.
  • Assicurarsi che le scritture siano allineate alle dimensioni del settore fisico segnalate.

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 settore a 512 byte, ovvero il ciclo Read-Modify-Write. Esaminiamo cosa accadrebbe se il processo di sovrascrittura del precedente settore fisico sui supporti 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 applicazioni 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 applicazione che causa un ciclo read-modify-write 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.

Tenendo presente questo aspetto, è importante che il software applicativo 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.

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

Evitare operazioni di 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 i problemi di prestazioni e resilienza del ciclo di lettura-modifica-scrittura, c'è solo tanta mitigazione che 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 questo non è una mitigazione in unità, ma per fare in modo che le applicazioni eseggano il set corretto di operazioni per evitare il ciclo Read-Modify-Write. In questa sezione vengono illustrati scenari comuni in cui le applicazioni 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 e 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). È 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 operazioni di scrittura 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 potrebbero causare problemi di prestazioni con alcuni dischi di formato avanzato.

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

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

Per determinare se l'applicazione genera problemi di I/O non memorizzati nel buffer, verificare 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 per le dimensioni del settore del supporto è veramente solo eseguire una query sull'unità di indirizzamento, ovvero le dimensioni logiche del settore. 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

Come eseguire una query per le dimensioni del settore fisico

Per un esempio di codice che mostra come un'applicazione può eseguire query sulle dimensioni del settore fisico del volume, vedere 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, 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'applicazione deve usare dimensioni del settore fisico uguali 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 dimensioni del settore fisico uguali alle dimensioni del settore logico segnalate.
  • Se la dimensione del settore fisico è un valore di potenza di due dimensioni 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'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 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.

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

I record di commit vengono riempiti in settori da 512 byte

Le applicazioni con un archivio dati in genere hanno 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 sulle dimensioni del settore fisico, come illustrato nella sezione precedente, e assicurarsi che ogni record di commit venga riempito in base a tale dimensione. In questo modo non solo si evita il ciclo Read-Modify-Write, che consente di garantire che, nel caso in cui un settore fisico sia andato perso, si perderebbe 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. 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 l'I/O memorizzato 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 assumere dimensioni di settore a 512 byte. Di conseguenza, gli aggiornamenti e le scritture in questo file comportano un ciclo Read-Modify-Write nel dispositivo, che potrebbe comportare problemi di prestazioni e resilienza per i clienti. Tuttavia, esistono modi per consentire a un'applicazione 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 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 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 applicazioni e può comportare potenzialmente la mancata inizializzazione di alcune applicazioni.

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 512e.

4 KB di supporti nativi

I supporti di emulazione a 512 byte sono destinati a un passaggio transitorio tra i supporti nativi a 512 byte e i supporti nativi di 4 KB e prevediamo di vedere 4 supporti nativi kb rilasciati poco dopo la disponibilità di 512e. Ci sono diverse implicazioni importanti con questi media che devono essere annotati:

  • Le dimensioni logiche e fisiche del settore sono entrambe di 4 KB
  • Poiché non esiste alcun livello di emulazione, le scritture non idonee non verranno superate dallo spazio 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 genererà un articolo della Knowledge Base quando appropriato, gli sviluppatori di applicazioni devono considerare la possibilità di fornire supporto preliminare per questi tipi di supporti.

Chiusura

In questo articolo sono stati illustrati gli effetti introdotti dai supporti di settore di grandi dimensioni 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 passando rapidamente ai supporti con dimensioni del settore maggiori e presto i clienti non potranno acquistare dischi con dimensioni tradizionali di settore a 512 byte.

Si tratta di un documento vivente e 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.