bs=128Ktl;dr - 當我使用 指定 a或更高值時，我的 ZFS RAIDZ2 陣列讀取速度為 7.5+ GB/s，寫入速度為 2.0+ GB/s dd。 OS X 假設 1K（根據stat -f %k .），我的全部是 ~300MB/s；dd給出與 相同的性能bs=1k。即使 abs=4k與 dd 也能提供 1.1GB/s。
如何將一般 I/O 提高到至少 1GB/s？
--
細節：
我正在 OSX (v1.31r2) 檔案系統 (v5000) 上透過 Thunderbolt 2（雙 Areca 8050T2）在 12 核心 64GB Mac Pro 上運行 16 磁碟機 SATA3 RAIDZ2 OpenZFS。
ZFS 檔案系統是使用ashift=12（具有 4096 位元組區塊的高級格式 HDD）和recordsize=128k.
我看到 OS X 中的陣列和使用預設命令的終端的傳輸速率約為 300MB/s（注意複製的檔案是 10GB 隨機資料）：
普通副本：
Titanic:lb-bu admin$ time cp big-test.data /dev/null
real 0m23.730s
user 0m0.005s
sys 0m12.123s
約 424 MB/秒
--
dd和bs=1k：
Titanic:lb-bu admin$ time dd if=./big-test.data of=/dev/null bs=1024
9841180+0 records in
9841180+0 records out
10077368320 bytes transferred in 32.572506 secs (309382653 bytes/sec)
real 0m32.575s
user 0m1.880s
sys 0m30.695s
約 309 MB/秒
--
dd和bs=4k
Titanic:lb-bu admin$ time dd if=./big-test.data of=/dev/null bs=4096
2460295+0 records in
2460295+0 records out
10077368320 bytes transferred in 8.686014 secs (1160183301 bytes/sec)
real 0m8.688s
user 0m0.460s
sys 0m8.228s
約1.16GB/秒
-
dd和bs=2m：
Titanic:lb-bu admin$ time dd if=./big-test.data of=/dev/null bs=2m
4805+1 records in
4805+1 records out
10077368320 bytes transferred in 1.162891 secs (8665788130 bytes/sec)
real 0m1.165s
user 0m0.003s
sys 0m1.162s
約8.67GB/秒
--
OS X's read of the boot drive optimal I/O block size (1TB SSD, HFS+):
Titanic:lb-bu admin$ stat -f %k /
4096
--
OS X's read of the array's optimal I/O block size (16-drives RAIDZ2, ZFS):
Titanic:lb-bu admin$ stat -f %k .
1024
--
我還在檔案系統旁邊的池上建立了一個 ZFS 卷，並格式化為 HFS+。我得到了與上面相同的性能。
我的運行速度比最佳值低約 20-30 倍！我缺什麼？有任何想法嗎？
--
更新：高速緩存 I/O（感謝@yoonix）。對於該硬體來說，約 300MB/s 的速度仍然顯得太慢。
@qasdfdsaq：I/O 期間的 CPU 使用率可以忽略不計（所有核心 <5%）。
zfs 取得所有輸出：
NAME PROPERTY VALUE SOURCE
lb-bu type filesystem -
lb-bu creation Tue Sep 30 16:41 2014 -
lb-bu used 36.8T -
lb-bu available 10.0T -
lb-bu referenced 138M -
lb-bu compressratio 1.00x -
lb-bu mounted yes -
lb-bu quota none default
lb-bu reservation none default
lb-bu recordsize 128K default
lb-bu mountpoint /Volumes/lb-bu local
lb-bu sharenfs off default
lb-bu checksum on default
lb-bu compression lz4 local
lb-bu atime on default
lb-bu devices on default
lb-bu exec on default
lb-bu setuid on default
lb-bu readonly off default
lb-bu zoned off default
lb-bu snapdir hidden default
lb-bu aclmode discard default
lb-bu aclinherit restricted default
lb-bu canmount on default
lb-bu xattr on default
lb-bu copies 1 default
lb-bu version 5 -
lb-bu utf8only on -
lb-bu normalization formD -
lb-bu casesensitivity insensitive -
lb-bu vscan off default
lb-bu nbmand off default
lb-bu sharesmb off default
lb-bu refquota none default
lb-bu refreservation none default
lb-bu primarycache all default
lb-bu secondarycache all default
lb-bu usedbysnapshots 0 -
lb-bu usedbydataset 138M -
lb-bu usedbychildren 36.8T -
lb-bu usedbyrefreservation 0 -
lb-bu logbias latency default
lb-bu dedup off default
lb-bu mlslabel none default
lb-bu sync standard default
lb-bu refcompressratio 1.01x -
lb-bu written 138M -
lb-bu logicalused 36.8T -
lb-bu logicalreferenced 137M -
lb-bu snapdev hidden default
lb-bu com.apple.browse on default
lb-bu com.apple.ignoreowner off default
lb-bu com.apple.mimic_hfs off default
lb-bu redundant_metadata all default
lb-bu overlay off default
答案1
您沒有zpool status為此發布，但您在帖子中暗示所有 16 個磁碟都位於 RAIDZ2 中的單一 vdev 中。雖然這是一個良好、安全的配置，但您必須了解 RAIDZ 的設計主要不是為了速度。它的設計接近防彈。 RAIDZ2 類似於 RAID6，但該變體具有使其速度更慢且更安全的功能。
看這篇寫得不錯有關完整的詳細信息，但這兩個引用應該可以幫助您了解問題（強調我的）：
寫入 RAID-Z vdev 時，每個檔案系統區塊都會在（可能）RAID-Z vdev 的所有裝置上分割成自己的條帶。這意味著每個寫入 I/O 都必須等待 RAID-Z vdev 中的所有磁碟都完成寫入。因此，從單一應用程式等待其 IO 完成的角度來看，您將獲得 RAID-Z vdev 中最慢磁碟的 IOPS 寫入效能。
從RAID-Z vdev 讀取時，適用相同的規則，因為該過程本質上是相反的（沒有像鏡像情況那樣的循環快捷方式）：如果幸運的話，頻寬會更好（並且讀取方式與編寫的方式相同）大多數情況下單一磁碟的 IOPS 讀取效能很重要。
實際上，您有 16 個中速驅動器，對於每次寫入，您都會等待所有 16 個驅動器與控制器進行檢查並在下一次寫入開始之前說「完成」。對於 16 個磁碟，您實際上總是要在其中一項寫入之前等待接近滿的磁碟旋轉，因此您會受到物理和 ZFS 提交資料方式的阻礙。
一般來說，單一進程/執行緒寫入任務並不是 ZFS 的最佳情況。一次執行多個小數據讀取/寫入任務可能會顯示更好的 IOPS 數字，但我認為 ZFS 的物理原理是您的主要問題。
如果您願意犧牲空間，鏡像可能會更快。透過在池中建立 2 個 8 磁碟 RAIDZ2 vdev（而不是 1 個 16 磁碟 RAIDZ2 vdev），您還可以從 ZFS 中獲得稍微更好的效能。這也會消耗您的可用儲存空間，但可能有助於更快地進行提交。
不幸的是我沒有好消息告訴你。