有兩種傳統的方法來把文件系統的元數據 (meta-data) 寫入磁盤。 (Meta-data更新是更新類似 inodes 或者目錄這些沒有內容的數據)
從前，默認方法是同步更新這些元數據(meta-data)。如果一個目錄改變了，系統在真正寫到磁盤之前一直等待。文件數據緩存(文件內容)在這之後以非同步形式寫入。這麼做有利的一點是操作安全。如果更新時發生錯誤，元數據(meta-data) 一直處於完整狀態。文件要不就被完整的創建要不根本就不創建。如果崩潰時找不到文件的數據塊，fsck(8) 可以找到並且依靠把文件大小設置為 0 來修復文件系統。另外，這麼做既清楚又簡單。缺點是元數據(meta-data)更新很慢。例如 rm -r 命令，依次觸及目錄下的所有文件，但是每個目錄的改變(刪除一個文件)都要同步寫入磁盤。 這包含它自己更新目錄，inode 表和可能對文件分散的塊的更新。 同樣問題出現大的文件操作上(比如 tar -x)。
第二種方法是非同步元數據更新。這是 Linux/ext2fs 和 *BSD ufs 的 mount -o async 默認的方法。所有元數據更新也是通過緩存。也就是它們會混合在文件內容數據更新中。這個方法的優點是不需要等待每個元數據更新都寫到磁盤上，所以所有引起元數據更新大的操作比同步方式更快。同樣，這個方法也是清楚且簡單的，所以代碼中的漏洞風險很小。缺點是不能保證文件系統的狀態一致性。如果更新大量元數據時失敗 (例如掉電或者按了重啟按鈕)，文件系統會處在不可預知的狀態。系統再啟動時沒有機會檢查文件系統的狀態；inode 表更新的時候可能文件的數據塊已經寫入磁盤了但是相關聯的目錄沒有，卻不能用 fsck 命令來清理(因為磁盤上沒有所需要的信息)。如果文件系統修復後損壞了，唯一的選擇是使用 newfs(8) 並且從備份中恢復它。
這個問題通常的解決辦法是使用 dirty region logging 或者 journaling 盡管它不是一貫的被使用並且有時候應用到其他的事務紀錄中更好。這種方法元數據更新依然同步寫入，但是只寫到磁盤的一個小區域。過後他們將會被移動到正確的位置。因為紀錄區很小，磁盤上接近的區域磁頭不需要移動很長的距離，所以這些比寫同步快一些。另外這個方法的復雜性有限，所以出現錯誤的機會也很少。缺點是元數據要寫兩次 (一次寫到紀錄區域，一次寫到正確的區域)。正常情況下，悲觀的性能可能會發生。從另一方面來講，崩潰的時候所有未發生的元數據操作可以很快的在系統啟動之後從記錄中恢復過來。
Kirk McKusick，伯克利 FFS 的開發者，用 Soft Updates 解決了這個問題：元數據更新保存在內存中並且按照排列的順序寫入到磁盤 (“有序的元數據更新”)。這樣的結果是，在繁重的元數據操作中，如果先前的更新還在內存中沒有別寫進磁盤，後來的更新就會捕捉到。所以所有的目錄操作在寫進磁盤的時候首先在內存中執行 (數據塊按照它們的位置來排列，所以它們不會在元數據前被寫入)。如果系統崩潰了這將導致一個固定的 “日志回朔”：所有不知如何寫入磁盤的操作都像沒有發生過一樣。文件系統的一致性保持在 30 到 60 秒之前。它保證了所有正在使用的資源被標記例如塊和 inodes。崩潰之後，唯一的資源分配錯誤是一個實際是“空閒”的資源的資源被標記為“使用”。 fsck(8) 可以認出這種情況並且釋放不再使用的資源。它對於忽略崩潰後用 mount -f 強制掛上的文件系統的錯誤狀態是安全的。 為了釋放可能沒有使用的資源，fsck(8) 需要在過後的時間運行。一個主意是用 後台 fsck：系統啟動的時候只有一個文件系統的 快照 被記錄下來。fsck 可以在過後運行。所有文件系統可以在“有錯誤”的時候被掛接，所以系統可以在多用戶模式下啟動。接著，後台 fsck 可以在所有文件系統需要的時候啟動來釋放可能沒有使用的資源。 (盡管這樣，不用 Soft Updates 的文件系統依然需要通常的 fsck。)
它的優點是元數據操作幾乎跟非同步一樣快 (也就是比需要兩次元數據寫操作的 logging 更快)。缺點是代碼的復雜性(意味著對於丟失用戶敏感數據有更多的風險) 和高的內存使用量。另外它有些特點需要知道。崩潰之後，文件系統狀態會“落後”一些。同步的方法用 fsck 後在一些地方可能產生一些零字節的文件， 這些文件在用 Soft Updates 文件系統之後不會存在，因為元數據和文件內容根本沒有寫進磁盤(可能發生在運行 rm 之後)。這可能在文件系統上安裝大量數據時候引發問題，沒有足夠的剩余空間來兩次存儲所有文件。
