SMR 為希望隨機寫入的 LBA 使用映射系統，以便僅按順序寫入它們。 類似於 SSD 的閃存轉換層 (FTL)，SMR HDD 使用有時稱為 SMR（或 Shingle）轉換層 (STL) 的概念，這是一個類似的概念。 然而，對於 SMR，通過讓主機了解底層 SMR 技術可以獲得更多。 該行業正處於 SMR 標準化過程的最後階段，ZBC（分區塊命令）是 SAS 的標準，ZAC（分區 ATA 命令）是 SATA 的標準。 這些標准定義了一個 Zoned Block Device，其中 LBA 空間被劃分為獨立的 Zones。 在每個區域中，寫入應該是連續的。 為了覆蓋數據，必須先重置區域，類似於 SSD 中的擦除塊。 將非順序寫入發送到區域時會發生什麼情況，具體取決於 SMR 實現的類型。
SMR 為希望隨機寫入的 LBA 使用映射系統，以便僅按順序寫入它們。 類似於 SSD 的閃存轉換層 (FTL)，SMR HDD 使用有時稱為 SMR（或 Shingle）轉換層 (STL) 的概念，這是一個類似的概念。 然而，對於 SMR，通過讓主機了解底層 SMR 技術可以獲得更多。 該行業正處於 SMR 標準化過程的最後階段，ZBC（分區塊命令）是 SAS 的標準，ZAC（分區 ATA 命令）是 SATA 的標準。 這些標准定義了一個 Zoned Block Device，其中 LBA 空間被劃分為獨立的 Zones。 在每個區域中，寫入應該是連續的。 為了覆蓋數據，必須先重置區域，類似於 SSD 中的擦除塊。 將非順序寫入發送到區域時會發生什麼情況，具體取決於 SMR 實現的類型。
SMR 驅動器分為三類，或者更準確地說，管理驅動器供應商可以使用三種類型。 每個都有自己的優點和缺點。
驅動管理
第一種類型稱為驅動器託管，也稱為透明。 簡單地說，SMR 驅動器管理來自主機的所有請求，就像今天的傳統硬盤一樣。 Drive managed 的優點是不需要 SMR 感知的主機，驅動器管理的 SMR 與幾乎所有東西兼容，使它們最易於部署。 底層 SMR HDD 的分區性質對主機完全隱藏。 這是我們期望在最初的消費市場版本中普遍可用的 SMR 管理類型，因為在撰寫本文時還沒有支持 SMR 驅動器的商用操作系統或文件系統。 然而，隨著更多測試的完成以及 SMR 技術變得更加普及，我們將看到廣泛可用的支持 SMR 的操作系統和軟件堆棧。
託管驅動器的缺點是性能不可預測，因為驅動器會在需要時處理其後台進程，而不管 IO 請求如何。 此外，由於入站隨機寫入不會在主機端合併為順序寫入，因此與主機具有 SMR 意識的情況相比，驅動器處於更大的壓力之下，因此在持續的工作負載中性能較低。 驅動器管理的 SMR 驅動器通過利用某種“著陸區”來解決這些缺點，在其中可以在寫入磁盤之前管理隨機寫入。 但是，將此空間整合到 SMR 驅動器上的方法可能千差萬別，根據每個驅動器和製造商的目標市場，會導致顯著不同的性能配置文件。
主機託管
下一類型的管理稱為主機管理。 通過這種類型的管理，主機使用命令和區域信息通過管理 IO 來優化 SMR 驅動器的行為，以確保寫入始終在區域內按順序進行。 如果主機在區域中發送非順序寫入，驅動器將拒絕它並返回錯誤。 這為驅動器提供了更可預測的性能，並且更有可能最初出現在企業和超大規模應用程序中。
主機管理的缺點是 SMR 驅動器與不支持 SMR 的主機系統（HBA、設備驅動程序、文件系統、數據庫等）不兼容。 這意味著需要調整文件系統以支持 SMR 驅動器。 這種情況首先出現在超大規模領域，世界上最大的參與者有能力修改其存儲堆棧以考慮 SMR，現在也出現在主流開源領域。 xfs 維護者 Dave Chinner 在 XNUMX 月初於波士頓舉行的 Linux Vault 會議期間發布了一份文件，概述了 xfs 的 SMR 優化。 在同一事件中，Suse 的 Hannes Rienecke 提出了一種區域緩存機制，可以讓當前的文件系統與主機管理的 SMR 驅動器一起工作。 這些投資以及對容量的需求很可能會鼓勵其他人採用新的開源解決方案並對其係統進行修改以支持 SMR 驅動器。
主機感知
最後一種管理類型稱為主機感知。 簡而言之，主機感知是上述兩種管理的組合。 SMR 驅動器是自我管理的，但它也實施了新的 ZBC/ZAC 標準，並允許主機使用新的命令集來優化驅動器行為。 在這種情況下，如果驅動器從主機接收到非順序寫入，它將接受請求，但請求的性能可能無法預測。 主機感知具有向後兼容的優勢，並為主機提供了一些控制權。 主機感知可能是大多數客戶端和傳統企業系統的首選模型，接管所有驅動器管理部署，而主機管理開始成為現代分佈式存儲解決方案的選擇。
