不久前，有一些關於 ext4 在不乾淨的卸載後可能留下空文件的討論，總結得很好在本文中。基本上，由於延遲分配，寫入可以在寫入快取中保留比 ext 日誌的預設提交間隔（5 秒）更長的時間。
這些問題似乎已在補丁中修復，該補丁在某些情況下強制進行區塊分配，從而預設在最多 5 秒後強制將資料寫入磁碟。
我想知道當應用程式覆蓋文件的現有部分而不截斷或附加文件本身時會發生什麼。是否也會在 5 秒內強制寫入磁碟？
這似乎與附加到文件的情況不同：附加時，文件大小發生變化，這是元資料更改；因此，需要在 5 秒內提交日誌，並且由於 data=ordered，出於安全考慮，必須在此之前寫入資料（否則其他使用者已刪除文件的部分內容可能會顯示給附加文件的所有者）文件） 。
當僅覆蓋檔案資料時，沒有理由必須在元資料日誌提交之前進行資料寫入，因為舊資料與新資料屬於同一使用者。那麼寫入是否在提交之前發生，或者是否可以延遲比日誌提交間隔更長的時間？如果是這樣，需要多長時間？
更新：我知道當做正確的事情時，即使用 fsync() 時，所有這些都是無關緊要的。 （這是所有關於 ext4 和數據丟失的討論的主要原因 - 問題只涉及應用程序而不是 fsync()ing，或者不在正確的時刻。）我不是在編寫自己的應用程序，我問是因為我不知道我的所有應用程式是否都做了正確的事情，並且我想知道此類「危險」寫入的大致時間範圍。詢問的原因是我的顯示卡驅動程式經常導致核心恐慌，我想知道我是否需要擔心超過最後 5 秒的資料寫入。
答案1
您可以將提交間隔設為自訂值，我相信該值可以高達 32 位元無符號整數秒數；約 40 億秒，即 136 年。這可以透過commitmount 選項來實現，您可以如下使其生效（這只是一個範例；您也可以在 中設定fstab）：
mount /dev/sda1 -t ext4 -o rw,data=writeback,nobh,commit=12345678
提交間隔不基於任何類型的條件，例如是否附加資料或覆蓋現有資料等。 mount選項commit（如果您完全沒有提供 mount 選項，則預設為 5 秒）相當於在 bash shell 中執行類似的操作：
#!/bin/bash
while :
do
echo "Syncing all uncommitted data and journal to disk"
sync
sleep 5
done
不要混淆data=ordered這個全域檔案系統同步間隔（對於我們這些了解命令列程式功能的人來說，「提交間隔」可能是一個意義不大的術語sync，在這種情況下，最好將其命名為「同步間隔”）。data=ordered是關於命令其中資料和元資料被更新（其中data=writeback“不太安全/更快”和data=journal“更安全/更慢”）。commit=12345678是關於檔案系統驅動程式本身強制將所有髒資料/日誌/元資料/任何內容完全同步到實體媒體的頻率。如果您願意，當然可以將其設定為 136 年，並掛載那些data=writeback,nobh不呼叫fsync()或sync()將在 RAM 中保留髒頁的程式...幾個生命週期。
更新：根據您在問題編輯中的上下文，我想說您應該使用掛載選項data=journal,commit=1甚至使用sync掛載選項運行檔案系統，直到您能夠解決圖形驅動程式核心恐慌。這將保持最大的資料完整性，但會犧牲效能。如果您經常將無法承受遺失的資料寫入磁碟，那麼您會特別想要執行此操作，如果您不「信任」正在使用的應用程式能夠fsync()正確使用，那麼這一點就顯得尤為重要。
來源： 這裡和個人經歷
答案2
無論你的問題的答案是什麼，都沒關係。
這保證暴露ext4 檔案系統的行為是「成功sync/fsync呼叫後資料將保存在光碟上」。因此，如果您的應用程式讓您提出這個問題，您應該在需要確保資料完整性的關鍵點插入同步呼叫。如果您是擔心相同問題的用戶，您可以sync在執行任何可能導致不正常關閉的危險行為之前呼叫命令列實用程式。