有沒有辦法確定 dd 的 bs 參數的最佳值？
有時我在網上看到類似“確保設置’bs=’，因為預設值會花費太長時間”的評論，以及我自己極其不科學的經歷，“嗯，這似乎比其他人花費更長的時間上週的時間”似乎證明了這一點。因此，每當我使用“dd”（通常在 1-2GB 範圍內）時，我都會確保指定 bytes 參數。大約有一半的時間我使用我正在複製的任何線上指南中指定的值；其餘時間我會從“fdisk -l”列表中選擇一些有意義的數字，因為我認為是較慢的媒體（例如，我正在寫入的 SD 卡）。
對於給定的情況（媒體類型、匯流排大小或其他任何重要事項），有沒有辦法確定“最佳”值？容易確定嗎？如果沒有，有沒有一種簡單的方法可以達到 90-95% 的距離？或者“只選擇大於 512 的東西”甚至是正確的答案？
我曾經想過自己嘗試這個實驗，但是（除了做很多工作之外）我不確定哪些因素會影響答案，所以我不知道如何設計一個好的實驗。
dd可以追溯到需要翻譯舊的 IBM 大型機磁帶時，塊大小必須與用於寫入磁帶的大小相匹配，否則數據塊將被跳過或截斷。（9 磁軌磁帶很挑剔。很高興它們早就死了。）如今，塊大小應該是設備扇區大小的倍數（通常是 4KB，但在最近的磁碟上可能要大得多，而在非常小的拇指上驅動器可能更小，但無論如何 4KB 是一個合理的中間地帶）並且越大越好。我經常在硬碟上使用 1MB 的塊大小。（這些天我們也有更多的記憶要扔掉。）
只有一種方法可以確定最佳塊大小，這就是基準。我剛剛做了一個快速的基準測試。測試機器是一台執行 Debian GNU/Linux 的 PC，核心為 2.6.32，coreutils 為 8.5。涉及的兩個文件系統都是硬碟分區上 LVM 卷上的 ext3。源文件為 2GB（準確地說是 2040000kB）。啟用記憶體和緩衝。在每次執行之前，我都清空了記憶體
sync; echo 1 >|/proc/sys/vm/drop_caches。執行時間不包括最終sync刷新緩衝區；決賽sync時間為 1 秒。
same執行是同一文件系統上的副本；diff執行是複製到不同硬碟上的文件系統。為了保持一致性，報告的時間是使用實用程序獲得的掛鐘時間time，以秒為單位。我只執行了每個命令一次，所以我不知道時間上有多少差異。same diff t (s) t (s) dd bs=64M 71.1 51.3 dd bs=1M 73.9 41.8 dd bs=4k 79.6 48.5 dd bs=512 85.3 48.9 cat 76.2 41.7 cp 77.8 45.3**結論：**大塊大小（幾兆字節）有幫助，但不是很顯著（比我對相同驅動器副本的預期要少得多）。並且不要表現得那麼糟糕
cat。cp有了這些數字，我覺得不dd值得打擾。一起去cat！