我正在對基於SuperMicro E300-8D的小型伺服器盒進行基準測試。我安裝了帶有最新更新的最新 CentOS 7.5、64GB DDR4-2100 RAM 和三星 970 EVO 1TB NVMe SSD。作業系統安裝在內部 USB 埠的 USB 記憶棒上，因此 SSD 完全未使用，除非在我的基準測試期間。

我的測試目標是找到這個 SSD 的最佳並發級別，靈感來自ScyllaDB使用的基準測試方法。為此，我使用了 diskplorer，它在內部用於fio探索並發與 IOPS 和延遲之間的關係。它會生成方便的圖表，如下所示。在所有情況下，我都使用 4K 隨機讀取工作負載。

問題是我得到的結果毫無意義。這是第一個結果：

生的/dev/nvme0n1

$ sudo ./diskplorer.py --device=/dev/nvme0n1 --filesize=256G 

這是太棒了！三星自己的規格表聲稱 500K 讀取 IOPS 和 20 次並發讀取我得到近 600K。右邊的軸是以納秒為單位的讀取延遲，紅線是平均延遲，誤差線是 5% 和 95% 的延遲。所以看起來這個 SSD 的理想並發級別是大約 20 個並發讀取，產生的延遲小於 100us。

那隻是原始SSD。我將把 XFS 放在上面，它針對非同步 I/O 進行了優化，我相信它不會增加任何顯著的成本……

開啟新的 XFS 文件系統/dev/nvme0n1

$ sudo mkfs.xfs /dev/nvme0n1
$ sudo mount /dev/nvme0n1 /mnt
$ sudo ./diskplorer.py --mountpoint=/mnt --filesize=256G 

什麼！？太可怕了！XFS 似乎引入了一些荒謬的延遲並大大降低了 IOPS。有什麼問題？

以防萬一，重新啟動系統以清除記憶體，而不是記憶體應該是全新文件系統的一個因素：

/dev/nvme0n1重啟後XFS 開啟

$ sudo shutdown -r now
(reboot happens)
$ sudo mount /dev/nvme0n1 /mnt
$ sudo ./diskplorer.py --mountpoint=/mnt --filesize=256G 

不用找了。它與記憶體無關。

此時有一個有效的 XFS 文件系統/dev/nvme0n1，並且它被掛載到/mnt. 我將重複我首先做的測試，在未掛載的原始塊設備上，同時保留 XFS 文件系統的內容。

又生/dev/nvme0n1 了

$ sudo umount /mnt
$ sudo ./diskplorer.py --device=/dev/nvme0n1 --filesize=256G 

哦不，XFS 毀了我的 SSD 性能！ /sarcasm

顯然，並不是 XFS 嚴重破壞了我的 SSD 性能，或者 XFS 不適合這種工作負載。但它可能是什麼？即使解除安裝磁碟以不涉及 XFS，性能似乎也大大降低了？

憑直覺，我嘗試DISCARD了 SSD 的全部內容，這應該將磁碟內的單元分配重置為其原始狀態……

生/dev/nvme0n1後blkdiscard

$ sudo blkdiscard /dev/nvme0n1
$ sudo ./diskplorer.py --device=/dev/nvme0n1 --filesize=256G

奇蹟般地，我的 SSD 的性能恢復了。全世界都瘋了嗎？

根據@shodanshok 的建議，如果我dd在通過執行 a 來“修復”它之後對 SSD 執行 ablkdiscard怎麼辦？

原始/dev/nvme0n1然後blkdiscard歸零dd

$ sudo blkdiscard /dev/nvme0n1
$ sudo dd if=/dev/zero of=/dev/nvme0n1 bs=1M status=progress oflag=direct
$ sudo ./diskplorer.py --device=/dev/nvme0n1 --filesize=256G 

這是一個有趣的結果，並證實了我的信念，即 XFS 不應歸咎於此。僅通過用零填充 SSD，讀取延遲和吞吐量都顯著下降。所以一定是SSD本身對未分配扇區有一些優化的讀取路徑。

假設

顯然 XFS 並沒有殺死我的 SSD，如果是的話，blkdiscard也不會神奇地恢復它。我再次強調這些基準都是讀取基準，因此寫入日誌、寫入放大、磨損均衡等問題不適用。

我的理論是，這個 SSD 和可能的 SSD 通常在讀取路徑中進行了優化，它檢測到對磁碟未分配區域的讀取並執行高度優化的程式碼路徑，通過 PCIe 匯流排將全零發送回。

我的問題是，有人知道這是否正確嗎？如果是這樣，通常是否懷疑沒有文件系統的新 SSD 的基準測試，這是否記錄在任何地方？如果這不正確，是否有人對這些奇怪的結果有任何其他解釋？

大多數現代 SSD 使用基於頁面的映射表。起初（或在完整的 TRIM/UNMAP 之後）映射表為空 - 即任何 LBA 返回 0，即使底層快閃記憶體頁面/塊未完全擦除，因此其實際值與普通 0 不同。

這意味著，完成後blkdiscard，您並沒有從快閃記憶體晶片本身讀取；相反，控制器會立即將 0 返回給您的所有讀取。這很容易解釋你的發現。

一些更古老的 SSD 使用不同的、效率較低但更簡單的方法，這些方法總是從 NAND 晶片本身讀取。在這樣的驅動器上，修剪的頁面/塊的值有時是不確定的，因為控制器不是簡單地將它們標記為“空”，而是每次都從 NAND 讀取。

是的，SSD是比“普通” HDD 更複雜的野獸：畢竟，它們基本上是小型、自動包含、精簡配置的 RAID 卷，具有自己的文件系統/捲管理，稱為FTL（快閃記憶體轉換層）。

引用自：https://serverfault.com/questions/925543