512 位元組模擬 (512e) 磁碟相容性更新

  • 發行項

平台

用戶端 - Windows Vista、Windows 7、Windows 7 SP1
伺服器 - Windows Server 2008、Windows Server 2008 R2、Windows Server 2008 R2 SP1

功能影響

嚴重性 - 高
頻率 - 高

描述

經常性密度每年增加，而最近出現 3 TB 磁片時，用來處理減少訊號與雜訊比率 (SNR) 的錯誤修正機制會變得空間效率不佳，也就是需要增加的額外負荷，以確保媒體可供使用。 改善此錯誤修正機制的其中一個儲存產業解決方案是引進不同的實體媒體格式，其中包含較大的實體磁區大小。 這個新的實體媒體格式稱為 進階格式。 因此，對於新式存放裝置的磁區大小所做的任何假設不再安全，開發人員必須研究其程式碼基礎的假設，以判斷是否有影響。

本主題介紹軟體上進階格式儲存裝置的效果、討論應用程式可協助支援這種類型的媒體，並討論基礎結構，讓開發人員支援這些類型的裝置。 雖然本主題中呈現的內容提供改善進階格式磁片相容性的指導方針，但資訊通常會套用至具有進階格式磁片的所有系統。 下列版本的 Windows 提供查詢實體磁區大小的支援：

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

如需詳細資訊，請參閱 Windows 中大型磁區磁片磁碟機的 Microsoft 支援原則相關資訊。

如需進階格式磁片的詳細資訊，請連絡您的儲存體廠商。

邏輯與實體磁區大小

在媒體格式引進這項變更的其中一個考慮是與目前市場目前可用的軟體和硬體相容。 作為暫時解決方案，儲存體產業一開始引進了模擬一般 512 位元組磁區磁片的磁片，但透過標準 ATA 和 SCSI 命令提供真實磁區大小的相關資訊。 由於此模擬，有兩個磁區大小：

  • 邏輯磁區：用於媒體之邏輯區塊定址的單位。 我們也可以將其視為儲存體可接受的最小寫入單位。 這是模擬。

  • 實體磁區：單一作業中完成裝置讀取和寫入作業的單位。 這是不可部分完成寫入的單位。

大部分目前的 Windows API，例如IOCTL_DISK_GET_DRIVE_GEOMETRY會傳回邏輯磁區大小，但實體磁區大小可以透過IOCTL_STORAGE_QUERY_PROPERTY控制程式代碼擷取，其中包含在STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR結構的BytesPerPhysicalSector欄位中的相關資訊。 本文稍後會更詳細地討論這一點。

大型磁區媒體的初始類型

儲存體產業正在快速努力轉換至具有 4 KB 實體磁區大小的媒體這種新進階格式儲存體類型。 兩種類型的媒體將會發行至市場：

  • 4 KB 原生：此媒體沒有模擬層，並直接公開 4 KB 作為其邏輯和實體磁區大小。 Windows 和其他大部分作業系統目前不支援此媒體。 不過，Microsoft 正在調查未來版本的 Windows 中支援這種類型的媒體的可行性，並在適當時發出知識庫文章。
  • 512 位元組模擬 (512e) ：此媒體具有上一節所討論的模擬層，並公開 512 位元組作為其邏輯磁區大小， (類似于現今的一般磁片) ，但其實體磁區大小資訊 (4 KB) 可用。 這是數個儲存體廠商目前引進市場。 這個新媒體類型的整體問題在於，大部分的應用程式和作業系統都不知道實體磁區大小是否存在，這可能會導致許多問題，如下所示。

模擬的運作方式：讀取-修改-寫入 (RMW)

儲存媒體具有可修改實體媒體的特定單位。 也就是說，媒體只能以實體磁區大小的單位寫入或重寫。 因此，未在此單元層級執行的寫入需要額外的步驟，我們將在下列範例中逐步解說。

在此案例中，應用程式必須更新位於 512 位元組邏輯磁區內之 Datastor 記錄的內容。 下圖說明儲存裝置完成寫入所需的步驟：

在 512 位元組邏輯磁區內升級資料儲存體記錄所需的步驟

如上所示，此程式牽涉到儲存體裝置的一些工作，這可能會導致效能遺失。 若要避免此額外工作，必須更新應用程式以執行下列動作：

  • 查詢實體磁區大小。
  • 請確定寫入與回報的實體磁區大小對齊。

可讀寫的復原影響

復原功能說明應用程式能夠在會話之間復原狀態。 我們已瞭解 512e 儲存裝置執行 512 位元組磁區寫入 - 讀取修改-寫入週期的必要專案。 讓我們看看如果覆寫媒體上先前實體磁區的流程中斷，會發生什麼情況。 結果為何？

  • 因為大部分的硬碟都已就緒，實體磁區也就是實體磁區所在的媒體部分， 可能會因為部分覆寫而損毀不完整的資訊。 另一種方式是，您可以將它視為可能失去所有 8 個邏輯磁區 (實體磁區邏輯包含) 。

  • 雖然大部分具有資料存放區的應用程式都設計成能夠從媒體錯誤復原、遺失八個磁區或另一種方式，但遺失八個認可記錄，可能會讓資料存放區無法正常復原。 系統管理員可能需要從備份手動還原資料庫，甚至可能需要執行冗長的重建。

  • 其中一個重要影響是，另一個應用程式的行為會導致讀取-修改-寫入迴圈可能會遺失您的資料，即使您的應用程式未執行！ 這是因為您的資料和其他應用程式的資料可能位於相同的實體磁區內。

請記住，應用程式軟體務必重新評估程式碼中所採取的任何假設，並注意邏輯實體磁區大社區別，以及本文稍後討論的一些有趣的客戶案例。

如果您的應用程式依賴記錄結構資料存放區，就可能會發生此問題。

避免讀取修改-寫入

雖然某些儲存體廠商可能會在特定 512e 儲存裝置內引進某些層級的防護功能，以嘗試並協助減輕讀取-修改-寫入週期的效能和復原問題，但工作負載方面只有如此多的緩和措施可以處理。 因此，應用程式不應該依賴此風險降低作為長期解決方案。

此解決方案不是磁片磁碟機內防護功能，而是讓應用程式執行正確的一組動作，以避免讀取-修改-寫入迴圈。 本節討論應用程式可能會有大型磁區磁片問題的常見案例，並建議調查方式來嘗試並解決每個問題。

問題 1：分割區未對齊實體磁區界限

當系統管理員/使用者分割磁片時，第一個分割區可能尚未在對齊的界限上建立。 這可能會導致所有後續寫入變成未對齊實體磁區界限。 從 Windows Vista SP1 和 Windows Server 2008 開始，第一個分割區會放在磁片 4GB 或更大的磁片 (的前 1024 KB，否則對齊方式為 64 KB) 對齊 4 KB 實體磁區界限。 不過，假設 Windows XP 中的預設資料分割是協力廠商資料分割公用程式或使用不正確的 Windows API，建立的資料分割可能無法對齊實體磁區界限。 開發人員必須確定使用正確的 API 來協助確保對齊。 建議的 API 有助於確保資料分割對齊方式如下所述。

建立新的磁片區時， IVdsPack：：CreateVolume 和 IVdsPack2：：CreateVolume2 API 不會使用指定的對齊參數，而是使用作業系統的對齊值預設值， (Windows Vista SP1 會使用 63 個位元組，而 Windows Vista SP1 會使用上述預設值) 。 因此，建議需要建立分割區的應用程式改用 IVdsCreatePartitionEx：：CreatePartitionEx 或 IVdsAdvancedDisk：：CreatePartition API，以改用指定的對齊參數。

協助確保對齊正確的最佳方式是一開始建立分割區時正確執行。 否則，您的應用程式必須在執行寫入或初始化時納入考慮，這很複雜。 從 Windows Vista SP1 起，這通常不是問題;不過，舊版 Windows 可以建立未對齊的資料分割，這可能會導致某些進階格式磁片的效能問題。

問題 2：未緩衝寫入不符合實體磁區大小

基本問題在於未緩衝的寫入不會對齊儲存媒體的報告實體磁區大小，這會觸發磁片磁碟機中的讀取-Modify-Write，進而造成效能問題。 另一方面，緩衝寫入會與頁面大小 - 4 KB 一致，這與第一代大型磁區媒體的實體磁區大小一致。 不過，具有資料存放區的大部分應用程式都會執行未緩衝的寫入，因此必須確保這些寫入是以實體磁區大小的單位執行。

若要協助判斷應用程式是否發出未緩衝的 I/O，請在呼叫CreateFile函式時，檢查您是否在dwFlagsAndAttributes參數中包含FILE_FLAG_NO_BUFFERING旗標。

此外，如果您目前將寫入對齊磁區大小，此磁區大小很可能只是 邏輯 磁區大小，因為查詢媒體磁區大小的大部分現有 API 實際上只會查詢定址單位，也就是邏輯磁區大小。 此處感興趣的磁區大小是實體磁區大小，這是不可部分完成性的實際單位。 擷取邏輯磁區大小的一些 API 範例如下：

  • GetDiskFreeSpace、 GetDiskFreeSpaceEx
  • FileFsVolumeInformation
  • IOCTL_DISK_GET_DRIVE_GEOMETRY， IOCTL_DISK_GET_DRIVE_GEOMETRY_EX
  • IVdsDisk：：GetProperties、 IVdsDisk3：：GetProperties2

如何查詢實體磁區大小

Microsoft 在 MSDN 上提供了程式碼範例，詳細說明應用程式如何查詢磁片區的實體磁區大小。 程式碼範例位於 https://msdn.microsoft.com/library/ff800831.aspx 。

雖然上述程式碼範例可讓您取得磁片區的實體磁區大小，但您應該先對回報的實體磁區大小進行基本健全檢查，再使用它，因為觀察到某些驅動程式可能不會傳回正確格式化的資料：

  • 請確定回報的實體磁區大小為 > = 回報的邏輯磁區大小。 如果不是，您的應用程式應該使用等於報告邏輯磁區大小的實體磁區大小。
  • 請確定回報的實體磁區大小是兩個的乘冪。 如果不是，您的應用程式應該使用等於報告邏輯磁區大小的實體磁區大小。
  • 如果實體磁區大小是介於 512 位元組到 4 KB 之間的兩個乘冪值，您應該考慮使用實體磁區大小四捨五入到報告的邏輯磁區大小。
  • 如果實體磁區大小是大於 4 KB 的乘冪值，您應該先評估應用程式在使用該值之前處理此案例的能力。 否則，您應該考慮使用舍入為 4 KB 的實體磁區大小。

使用此 IOCTL 取得實體磁區大小有數個限制：

  • 需要提高的許可權。 如果您的應用程式未以許可權執行，您可能需要如上所述撰寫 Windows 服務應用程式。

  • 不支援 SMB 磁片區。 您可能也需要撰寫 Windows 服務應用程式，以支援這些磁片區上的實體磁區大小查詢。

  • 無法發出至任何檔案控制碼， (IOCTL 必須發出至磁片區控制碼) 。

  • 僅支援本文開頭附近的 Windows 版本。

認可記錄會填補到 512 位元組磁區

具有資料存放區的應用程式通常會有某種形式的認可記錄，可維護中繼資料變更的相關資訊，或維護資料存放區的結構。 為了確保遺失磁區不會影響多個記錄，此認可記錄通常會填補到磁區大小。 使用具有較大實體磁區大小的磁片時，應用程式必須查詢實體磁區大小，如上一節所示，並確保每個認可記錄都填補到該大小。 這不僅會避免讀取-修改-寫入迴圈，也有助於確保實體磁區遺失時，只會遺失一個認可記錄。

記錄檔會以未對齊的區塊寫入

更新或附加至記錄檔時，通常會使用未緩衝的 I/O。 有數種方式可協助確保這些更新正確對齊：

  • 在內部緩衝處理作業媒體回報的實體磁區大小更新，而且只有在實體磁區單位已滿時，才會發出記錄寫入
  • 使用緩衝 I/O

問題 3：依賴 512 位元組磁區的檔案格式

某些具有標準檔案格式的應用程式 (例如 VHD 1.0) ，可能會有這些檔案硬式編碼，以假設 512 位元組磁區大小。 因此，更新和寫入此檔案會導致裝置上的讀取-Modify-Write 迴圈，這可能會導致客戶的效能和復原問題。 不過，有一些方法可讓應用程式支援在這種類型的媒體上運作，例如：

  • 使用緩衝處理來確保寫入是以實體磁區大小的單位執行
  • 實作內部讀取-修改-寫入，以協助確保更新會以回報的實體磁區大小單位執行
  • 可能的話，填補會記錄到實體磁區，如此一來，填補就會解譯為空白空間
  • 請考慮重新設計新版本的應用程式資料結構，並支援較大的磁區

問題 4：回報的實體磁區大小可以在會話之間變更

在許多情況下，裝載 Datastor 的基礎儲存體回報實體磁區大小可能會變更。 最常見的情況是當您將資料儲存體移轉至另一個磁片區，或甚至透過網路。 報告實體磁區大小的變更可能是許多應用程式的未預期事件，而且可能會導致某些應用程式甚至無法重新初始化。

這不是支援的最簡單案例，這裡會以諮詢的形式提及。 您應該考慮客戶的行動需求，並據以調整您的支援，以確保客戶不會受到 512e 媒體的負面影響。

4 KB 原生媒體

512 位元組模擬媒體是 512 位元組原生和 4 KB 原生媒體之間的過渡步驟，我們預期會在 512e 之後不久發行 4 KB 原生媒體。 此媒體有數個重要影響，應該注意：

  • 邏輯和實體磁區大小都是 4 KB
  • 因為沒有模擬層，所以儲存體將會失敗未對齊的寫入
  • 沒有隱藏的復原命中 – 應用程式運作或無法運作

雖然 Microsoft 目前正在調查未來版本的 Windows 中對這些媒體類型的支援，並在適當時發出 KB 文章，但應用程式開發人員應該考慮先先提供這些媒體類型的支援。

關閉

在本文中，我們已討論大型磁區媒體在許多常見部署案例中引進的影響。 我們已看到「讀取修改-寫入」的效能和復原影響、此媒體可以引進的一些有趣案例，以及它們可能會對軟體造成的問題集，最終會影響使用者。 儲存體產業會快速轉換至具有較大磁區大小的媒體，而且很快的客戶將無法購買具有傳統 512 位元組磁區大小的磁片。

這是一份生活檔，旨在協助開發人員瞭解此轉換。 您應該開始與個別組織、客戶、IT 專業人員和硬體廠商交談，以討論大型部門轉換，以及其如何影響您重要的案例。