為什麼 ddrescue 在無錯誤區域可以更快，但速度卻很慢？
這個問題解決了要救援的設備的第一次通過。
ddrescue我不得不搶救一個 1.5TB 的硬碟。
我使用的命令是：
# ddrescue /dev/sdc1 my-part-img my-part-map當在磁碟的良好區域上啟動救援（沒有可選參數）時，讀取速率（“
current rate”）保持在 18 MB/s 左右。它偶爾會減慢一點，但隨後又恢復到這個速度。
但是，當它遇到磁碟壞區時，它可能會明顯變慢，然後再也回不到18 MB/s，而是保持在3 MB/s左右，即使讀取了50 GB的好磁碟也沒有問題.
奇怪的是，當它目前以 3 MB/s 的速度掃描一個好的磁碟區域時，如果我停止
ddrescue並重新啟動它，它會以 18 MB/s 的更高讀取速率重新啟動。ddrescue實際上，當它以 3 MB/s 的速度執行時，我通過停止和重新啟動節省了大約 2 天的時間，我必須這樣做 8 次才能完成第一次通過。我的問題是：為什麼它
ddrescue不會自己嘗試回到最高速度。鑑於文件中明確說明的政策，即首先快速完成容易的區域，這是應該做的，而我觀察到的行為在我看來是一個錯誤。我一直想知道這個選項是否可以解決， 或者
-a手冊太簡潔了，我不確定。此外，我不明白應該在什麼基礎上為此選項選擇讀取率。應該是上面的18MB/s吧？--min-read-rate=…儘管如此，即使有一個選項來指定它，我很驚訝這不是預設完成的。
元註釋
兩名使用者投票結束了這個主要基於意見的問題。
我會很感激知道它是什麼意思？
我以某種數值精度描述了一個重要軟體在實際範例中的行為，清楚地表明它不符合其文件中所述的主要設計目標（盡可能快地完成簡單的部分），以及非常簡單的推理可以改善這一點。
該軟體眾所周知，來自一個非常值得信賴的來源，具有精確的算法，我希望大多數缺陷在很久以前就被淘汰了。因此，我向專家詢問這種意外行為的可能已知原因，而不是我自己在這個問題上的專家。
此外，我問是否應該使用軟體的選項之一來解決這個問題，這是一個非常精確的問題。我要求提供詳細的方面（如何為此選項選擇參數），因為我沒有找到相關文件。
我要的是我工作需要的事實，而不是意見。我用實驗事實而不是意見來激勵它。
我一直想知道這是否可以通過選項 -a 或 –min-read-rate= … 來處理，但手冊非常簡潔，我不確定。此外，我不明白應該在什麼基礎上為此選項選擇讀取率。應該是上面的18MB/s吧？
該
--min-read-rate=選項應該有所幫助。現代驅動器往往會花費大量時間進行內部錯誤檢查，因此雖然速度極慢，但不會將其報告為錯誤情況。即使在讀取 50 GB 的好磁碟後也沒有問題。
這也意味著：你甚至不知道是否有問題了。驅動器可能有問題，並決定不報告。
現在，
ddrescue支持使用動態--min-read-rate=值，來自info ddrescue：If BYTES is 0 (auto), the minimum read rate is recalculated every second as (average_rate / 10).但根據我的經驗，自動設置似乎沒有多大幫助。一旦驅動器卡住了，特別是如果剛開始就發生這種情況，我猜平均速率永遠不會保持足夠高以使其有效。
因此，在第一次通過時，當您想獲取盡可能多的數據時，首先是快速區域，我只是將其設置為
average_rate / 10手動，average_rate 是驅動器完好無損時的平均速率。因此，例如，您可以使用
10M此處（對於應該以 ~100M/s 的速度執行的驅動器），然後您可以隨時返回並稍後在慢速區域嘗試運氣。我觀察到的行為在我看來是一個錯誤。
如果你有一個錯誤，那麼你必須調試它。如果沒有相同類型的驅動器故障，很難重現。它也可能是卡在某種恢復模式的驅動器本身。
在處理有缺陷的驅動器時，您還必須檢查
dmesg是否發生了任何奇怪的事情，例如匯流排重置等。一些控制器在處理故障驅動器方面也比其他控制器更差。有時無法避免人工干預。
即便如此，我很驚訝這不是預設完成的。
大多數程序都沒有健全的預設值。
dd預設情況下仍然使用 512 字節塊大小，在大多數情況下這是“錯誤”的選擇……被認為是理智的也可能隨著時間而改變。我要的是我工作需要的事實，而不是意見。
擁有良好的備份總比依賴
ddrescue. 從故障驅動器中獲取數據首先是運氣問題。數據恢復涉及很多個人經驗，因此 - 意見。我們擁有的大多數恢復工具也很愚蠢。該工具沒有向中央伺服器報告的人工智慧，並且就像“哦，我以前在這個特定的驅動器模型上看到過這種故障模式，所以讓我們改變我們的策略……”。所以這部分必須由人來完成。