測試磁碟寫入
我正在編寫一個用於在 ext3 文件系統上儲存大量圖像（大小 <5MB）的應用程序，這就是我現在所擁有的。在對 serverfault 進行一些搜尋後，我決定採用如下目錄結構：
000/000/000000001.jpg ... 236/519/236519107.jpg這種結構將允許我最多保存 1'000'000'000 張圖像，因為我將在每片葉子中最多儲存 1'000 張圖像。
我已經創建了它，從理論上講對我來說似乎沒問題（儘管我沒有這方面的經驗），但我想知道當目錄中充滿文件時會發生什麼。
關於創建此結構的一個問題：一次創建所有內容更好（在我的電腦上大約需要 50 分鐘）還是應該根據需要創建目錄？從開發人員的角度來看，我認為第一個選項更好（使用者沒有額外的等待時間），但從系統管理員的角度來看，這樣可以嗎？
我認為我可以像文件系統已經在執行的應用程序下一樣做，我將製作一個腳本，盡可能快地保存圖像，監控如下：
- 在沒有或很少使用空間的情況下保存圖像需要多長時間？
- 當空間開始用完時，這將如何變化？
- 從隨機葉子中讀取圖像需要多長時間？當有很多文件時，這會發生很大變化嗎？
是否啟動此命令
sync; echo 3 | sudo tee /proc/sys/vm/drop_caches有任何意義嗎？如果我想重新開始我的測試，這是我唯一需要做的事情嗎？
您有什麼建議或更正嗎？
編輯：由於這兩個問題，我選擇了文件系統，而不是數據庫：
Pehrs 提出了一個關於具有這麼多文件的文件系統的非常好的觀點。當需要備份該文件系統時，將需要很長時間。文件遍歷是備份過程中最耗時的事情之一，就在所有這些文件打開/文件關閉請求中。問題“當沒有或很少使用空間時保存圖像需要多長時間？ ”表明這些文件將非常小，因此這種類型的文件系統幾乎是最壞情況備份的教科書場景（一種情況更糟：所有這些文件都在一個目錄中）。
與真正的數據庫相比，將數據庫轉儲到備份是一種非常快速、高效的操作。是的，該數據庫可能非常大，但它會更快地備份，甚至可以隨著文件數量的增長更快地提供數據。它可能取決於您使用的 DB 以及它的管理程度，但通常在這種情況下使用 DB 儲存而不是 FS 儲存將提供更好的災難恢復能力。
如果數據庫不是一個選項，那麼是的，預先創建目錄結構是你最好的選擇。還有助於在整個結構中平衡文件創建的負載，而不僅僅是在 /000/000/ 被填充之前再移動到 /000/001/。這應該確保每個目錄的文件數在相當長的一段時間內保持低水平。