Linux
ext4 文件系統安全嗎？
最近，我的磁碟格式化為
etx4. 老實說，我相信失敗是站在我這邊的，因為其中一個是由於不正確$$ manual $$解除安裝快閃記憶體卡，另一個與斷電有關。最終效果是我物理上失去了 128 GB 快閃記憶體卡$$ with money related $$以及有關 2Tb 硬碟的資訊$$ with time related $$. 我主要擔心的是這種損壞永遠不會發生在分區到的磁碟上
NTFS，無論如何。 我的問題是：
- ext4 一般安全嗎？我的意思是是我還是其他人在格式化為的磁碟上失去了磁碟/資訊
etx4？- 在 Linux 世界中，有什麼
ext4比意外斷電或意外解除安裝更安全的替代方案？
我主要擔心的是這種損壞永遠不會發生在分區到 NTFS 的磁碟上，無論如何。
它可能從未發生在你身上，但它已經發生了。唯一可以聲稱這種事情從未發生過的文件系統是那些從未暴露於這種情況的文件系統。即使是 BTRFS 和 ZFS，它們都被設計為對此類問題具有彈性，也可能存在此類問題。
不過，對於您的實際問題：
ext4 一般安全嗎？我的意思是是我還是其他人在格式化為 etx4 的磁碟上失去了磁碟/資訊？
這取決於您所說的“安全”是什麼意思。我個人在用 格式化的磁碟上失去了數據
ext4，但每次發生在我身上都是由於硬體故障，更重要的是，它最終會在幾乎任何其他文件系統中發生。儘管如此，我仍然會定期將它用於許多事情，因為除非使用者錯誤或硬體問題（包括意外斷電），否則它可以正常工作。所以，按照大多數人的定義，我認為它是“安全的”，但你可能會也可能不會。在 Linux 世界中，有什麼比 ext4 更安全的替代品可以比意外斷電或意外解除安裝更長壽？
不，除非您想處理其他限製或問題。尤其：
- XFS 對意外斷電更有彈性，並且不需要像 ext4 那樣在重啟時進行長時間檢查，但有許多實際限制，使其在小規模使用時存在問題（不能縮小文件系統，性能不是在新卷上與 ext4 一樣好，不能做數據日誌）。
- NILFS2 幾乎不可能因電源故障而被殺死，但您可能會失去 30 秒左右的更改，它在掛載時需要一個使用者空間組件，並且它缺少一些通常被大多數 Linux 文件系統視為標準的功能。
- BTRFS 將使您免於發生故障的硬體並且相當可靠，此外它還為線上更換故障磁碟提供了很好的支持，但是您可能會在意外斷電時失去一些最新的更改，並且您需要做更多的工作來保持卷比大多數其他文件系統健康。
- ZFS 具有 BTRFS 的所有好處，沒有任何問題（管理問題除外），但它需要您建構第三方核心模組，如果您遇到任何問題，您將無法獲得任何上游支持不在企業級硬體上執行。
但是，您可以做很多事情來使 ext4 更安全：
- 遇到錯誤時更改行為。預設情況下，如果在文件系統元數據中遇到錯誤，ext4 只會將該卷標記為需要檢查，然後就像什麼都沒發生一樣。它是Linux 上唯一執行此操作的文件系統，其他所有內容都將以只讀方式重新安裝卷，從而防止對文件系統的任何寫入使事情變得更糟。
errors=remount-ro您可以通過添加到掛載選項或tune2fs -e remount-ro在包含文件系統的塊設備上執行來在 ext4 上獲得此行為。- 確保您沒有為日誌使用寫回模式。你可以通過仔細檢查卷的安裝選項並確保它
journal=writeback不在列表中來確保這一點。日誌寫回模式可以顯著提高 ext4 文件系統上某些工作負載的性能，但如果您意外斷電，則更有可能失去數據。- 如果您想對數據安全持懷疑態度，可以啟用日誌數據模式。通常，ext4 文件系統上的日誌僅跟踪元數據的更改（重命名、文件刪除或創建、時間戳更新等）。在日誌數據模式下，所有更改都通過日誌。這會顯著減慢速度，但在功能上 100% 保證文件系統將保持內部一致。您可以通過傳入
journal=data掛載選項來啟用此功能。- 您可以添加
auto_da_alloc掛載選項。本質上，這會檢測到應用程序沒有fsync()在應該呼叫的時候呼叫，並正確處理事情。這不是預設設置，因為它會減慢速度，並且大多數應用程序不需要它。- 在較新的核心上，您可以啟用日誌校驗和。這實際上不會“保存”您的數據，但它有助於確保您在出現錯誤時不會取回虛假數據。這可以通過添加
journal_checksum到安裝選項來啟用。- 如果您有足夠新的核心和 e2fsprogs 版本，則可以啟用元數據校驗和。與日誌校驗和類似，這不會保存您的數據，但如果出現錯誤，它將有助於防止您看到虛假數據。這必須在文件系統創建時通過傳遞
-O metadata_checksum,metadata_checksum_seed給mkfs.ext4. 如果你這樣做，你（可能）不需要啟用日誌校驗和，因為日誌是元數據校驗和覆蓋的一部分。