（我無法找到明確的答案我的問題，也許我用了錯誤的搜索詞）寫入多個文件比較。寫一個大文件[在固態驅動器]
我想記錄許多圖像從相機，與沒有壓縮或無損壓縮，只有一個固態驅動器的功能不是很強大。 經過調查，我已經決定，如果有的話，壓縮將只是按圖像形式（這不是討論的一部分）。 鑑於這些限制，我希望能夠以最大可能的頻率從相機拍攝。瓶頸是（只有一個）硬盤的速度。我想使用RAM來排隊，而少數可用內核用於並行壓縮圖像，以便寫入的數據更少。
一旦數據被壓縮，如果我將所有字節流到一個單獨的文件中，或者考慮到我正在使用固態驅動器，我可以只寫一個文件（我們假設大約1或2 MB）每個圖像仍然在最大磁盤帶寬下工作？ （或非常接近它，像> 90％）？
我不知道它是否重要，這將使用C++及其庫。
我的問題是「簡單」，如果通過在單個文件中寫入輸出而不是在許多2MB文件中使用固態驅動器，我可以預期會帶來顯着的好處。
有一個好處，而不是一個重要的。用於固態驅動器的文件系統驅動程序已經知道如何將文件的數據分佈到許多非相鄰的羣集中，因此自己做這件事並沒有幫助。必須在已包含文件的驅動器上安裝大文件。通過分解，你強制額外寫入也添加這些段的目錄條目。
固態驅動器的類型很重要，但驅動程序通常已經完成「磨損平衡」。換句話說，故意分散驅動器上的數據。這樣可以避免耗盡閃存單元，它們只能在物理磨損和故障發生之前將其寫入有限的次數。傳統上只保證10,000次寫入，他們已經變得更好。你當然會練習這個。值得注意的是，閃存驅動器讀取速度快，但寫入速度慢，這對您的情況至關重要。
將圖像數據分解爲單獨的文件有一個顯着的優點：從驅動器錯誤中恢復更容易。無論是來自災難性的失敗，還是驅動力不足，都無法及時停下來。你不會失去整個鏡頭。但不管什麼程序讀取驅動器上的圖像，都必須將它們粘合在一起。這也是一個重要的設計目標，如果你使用非標準的非壓縮文件格式實現它太不切實際，或者傳輸速度太慢，或者一般太不方便，那麼它就不會經常使用。
我想知道額外寫入更新文件系統有多大影響......這聽起來效率很低，但是在這裏我還不知道文件系統如何處理更新目錄內容。如果將數據分散到驅動器中的塊大小比在多次寫入操作中僅寫入一次的數據塊小，那麼知道這些塊的典型大小會很有趣 – Antonio
我不明白爲什麼您不會只是編寫一個測試程序，寫一個大文件並在設備上運行它。現在你知道*而不必依賴SO用戶的猜測，他們不知道你正在使用的實際硬件。 –
我試圖看看有沒有人有過這種問題/選擇的經驗（我認爲這可能是一個相當標準的問題，但令人驚訝的是谷歌沒有給出任何有用的結果），我還沒有訪問確切的硬件，我現在必須使用，而軟件必須提前準備好。 – Antonio
制定切合實際的項目目標是至關重要的，目前還沒有證據表明您已經到達那裏。這確實需要從你發現設備的能力開始。從那裏你會知道什麼是可能的，這是不能用其他方式工作的。幾乎不可避免的是，你會發現你不得不調整無壓縮要求或忍受冰川射擊率。 –
@HansPassant無損壓縮是這類工作的唯一選擇。幾乎無法找到適用於灰度圖像的無損壓縮編碼解碼器。我可以以相對較低的幀率生活，無論如何我都想盡可能獲得最好的效果。我的問題是「簡單」，如果通過將輸出寫入單個文件而不是多個2MB文件中，我可以預期在使用固態驅動器時有顯着的優勢。我可能會在某個時候嘗試，但我試圖瞭解是否有人有過這方面的經驗。 – Antonio
我有點驚訝SSD應該是一個瓶頸。我們在談論每秒多少張圖片？如果I/O性能出現問題，我不會使用C++庫，而是使用重疊I/O的Windows API。 –