假設我的驅動器在某個隨機位置有一個壞的超級塊（或塊）。這是一個巨大的驅動器，1-8 TB。它不會格式化為 ext3，因此我將其寫滿零，以便我可以正確格式化它。lsblk -f將其 FSTYPE 顯示為空字串。
有什麼理由不運行下面的命令嗎？
sudo dd if=/dev/zero bs=10G status=progress of=/dev/bad_disk
答案1
我懷疑你不能在程式寫入區塊時中斷程序，並且寫入 10GB 需要大量時間。根據我的經驗，塊大小穩定的性能改進相當快，因此我會堅持使用更合理的大小（4MB ...）。
答案2
我的回答完全符合標題：
是否有任何反對使用
ddwith 的爭論bs=10G？
但就你的情況來說有點XY問題。根本問題（壞塊）應該用 和 來解決，smartctl而badblocks不是dd。
記憶體使用情況
這是另一個答案提到「透過區塊大小提高效能」：
塊大小穩定後的性能提升相當快
確實如此，但這只是bs故事中「接近零」的部分。在問題的背景下，我們應該告訴「bs走向無窮大」部分。
在現實世界中，高原實際上會塌陷一些大的區域bs。該bs=10G工具將嘗試分配 10 GiB 記憶體。它可能會成功，也可能不會成功（記憶體耗盡）。即使成功了，仍然存在一些問題：
- 其他進程可能會將其分配的記憶體換出到磁碟。
- 的緩衝區
dd可以換出到磁碟。該工具不斷使用它，因此作業系統可能會先交換其他（最近未存取的）資料。不過，如果您有 8 GiB RAM 和 16 GiB 交換空間，則無法容納bs=10GRAM。 - 如果以後需要記憶的話，OOM 殺手可能會發揮作用。您
dd可能是第一個被殺死的進程。
當然，這一切都取決於您有多少 RAM、有多少交換空間，以及其他進程的功能。
提示
我個人偏好使用bs在 0.1-1 秒內傳輸的大小；bs如果 RAM 使用可能是一個問題，則更小。這樣我dd幾乎可以立即打斷（這是重點已經提到的答案）。如果硬體限制允許dd超過 10 GiB/s 並且我有超過 40 GiB 的可用 RAM，我會考慮bs=10G.在家裡我幾乎從不去上面bs=64M。
一個bs=10G可能有用的用例是當您想要處理確切地您使用的資料量count=1（或例如 5 倍：）count=5。然而在實踐中bs你可能會得到較少的，除非您使用iflag=fullblock（參見這個答案）。由於記憶體使用，我bs無論如何都會重新計算為更小的值。