Linux中的文件編輯是否直接保存到磁碟中?
我以前認為文件更改是直接保存到磁碟中的,即只要我關閉文件並決定點擊/選擇保存。然而,在最近的一次談話中,我的一個朋友告訴我這通常不是真的。作業系統(特別是我們談論的 Linux 系統)將更改保存在記憶體中,並且它有一個守護程序,它實際上將內容從記憶體寫入磁碟。
他甚至舉了外部快閃記憶體驅動器的例子:它們被安裝到系統中(複製到記憶體中),有時會發生數據失去,因為守護程序尚未將內容保存到快閃記憶體中;這就是我們解除安裝快閃記憶體驅動器的原因。
我對作業系統的功能一無所知,所以我完全不知道這是否屬實以及在什麼情況下。我的主要問題是:這是否像 Linux/Unix 系統(可能還有其他作業系統)中描述的那樣發生?例如,這是否意味著如果我在編輯和保存文件後立即關閉電腦,我的更改很可能會失去?也許這取決於磁碟類型——傳統硬碟驅動器與固態磁碟?
該問題專門針對具有儲存資訊的磁碟的文件系統,即使任何澄清或比較都得到了好評。
如果我在編輯和保存文件後立即關閉電腦,我的更改很可能會失去?
他們可能是。我不會說“最有可能”,但可能性取決於很多事情。
提高文件寫入性能的一種簡單方法是讓作業系統只記憶體數據,告訴(欺騙)應用程序寫入過程,然後稍後實際執行寫入。如果同時有其他磁碟活動,這將特別有用:作業系統可以優先讀取並稍後執行寫入。它還可以完全消除對實際寫入的需要,例如,在之後快速刪除臨時文件的情況下。
如果儲存速度較慢,記憶體問題會更加明顯。將文件從快速 SSD 複製到慢速 USB 記憶棒可能會涉及大量寫入記憶體,因為 USB 記憶棒無法跟上。但是您的
cp
命令返回得更快,因此您可以繼續工作,甚至可能編輯剛剛複制的文件。當然,這樣的記憶體有你注意到的缺點,一些數據在實際保存之前可能會失去。如果他們的編輯告訴他們寫入成功,但文件實際上不在磁碟上,使用者會很生氣。這就是為什麼有
fsync()
系統呼叫的原因,它應該只在文件實際到達磁碟後才返回。在向使用者報告寫入成功之前,您的編輯器可以使用它來確保數據正常。我說“應該”,因為驅動器本身可能會對作業系統說同樣的謊言並說寫入已完成,而文件實際上只存在於驅動器內的易失性寫入記憶體中。根據驅動器,可能沒有辦法解決這個問題。
除了
fsync()
,還有sync()
和syncfs()
系統呼叫要求系統確保所有系統範圍的寫入或特定文件系統上的所有寫入都已命中磁碟。該實用程序sync
可用於呼叫這些。然後還有
O_DIRECT
to 標誌open()
,它應該是“盡量減少進出該文件的 I/O 的記憶體影響”。刪除記憶體會降低性能,因此主要由執行自己的記憶體並希望控制它的應用程序(數據庫)使用。(O_DIRECT
並非沒有問題,手冊頁中關於它的評論有些有趣。)斷電時會發生什麼也取決於文件系統。您應該關注的不僅僅是文件數據,還有文件系統元數據。如果找不到,將文件數據保存在磁碟上並沒有多大用處。僅將文件擴展為更大的大小將需要分配新的數據塊,並且需要在某處進行標記。
文件系統如何處理元數據更改以及元數據和數據寫入之間的順序變化很大。例如,
ext4
如果你設置了 mount 標誌data=journal
,那麼所有的寫入——甚至是數據寫入——都會通過日誌並且應該是相當安全的。這也意味著它們被寫入兩次,因此性能下降。預設選項嘗試對寫入進行排序,以便在更新元數據之前數據位於磁碟上。其他選項或其他文件系統可能更好或更差;我什至不會嘗試全面的研究。實際上,在負載較輕的系統上,文件應該在幾秒鐘內到達磁碟。如果您正在處理可移動儲存,請在拉取媒體之前解除安裝文件系統,以確保數據實際發送到驅動器,並且沒有進一步的活動。(或者讓您的 GUI 環境為您執行此操作。)