修復了文件系統錯誤

當我突然意識到我的所有文件都被標記為只讀時，我正在使用我的虛擬機。我覺得很奇怪，所以我重新啟動，然後我被提示進入“BusyBox”。由於某種未知原因，文件系統發生了錯誤。

我fcsk如下圖所示執行。理論上，它修復了不同的錯誤。

由於我不完全了解所做的fcsk事情，並且根據我之前在 Windows 修復其文件系統方面的經驗，我現在對文件系統是否真的“修復”或是否存在損壞的文件有點懷疑。

• 我可以相信修復過程嗎？
• 有沒有一種方法可以檢查所有數據是否正常，而不必一個一個打開文件？
• 當發生如下圖所示的錯誤時，會對驅動器中的實際數據產生什麼影響？我可以期待部分文件損壞嗎？完整的文件損壞？

---

一些單獨的錯誤消息：

File /var/log/journal/d74933508486479e9b07e83b9a036776/system.journal corrupted or uncleanly shut down, renaming and replacing.
pulseaudio[815]: ALSA woke us up to write new data to the device, but there was actually nothing to write.
pulseaudio[815]: Most likely this is a bug in the ALSA driver 'snd_ens1371'. Please report this issue to the ALSA developers.
pulseaudio[815]: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.
lightdm[931]: gkr-pam: unable to locate daemon control file
dbus-daemon[1035]: writing oom_score_adj error: Permission denied
colord[1570]: failed to get edid data: EDID length is too small
udisksd[1636]: failed to load module mdraid: libbd_mdraid.so.2: cannot open shared object file: No such file or directory
udisksd[1636]: Failed to load the 'mdraid' libblockdev plugin
udisksd[1636]: Error probing device: Error sending ATA command IDENTIFY PACKET DEVICE to '/dev/sr0': ATA command failed: error=0x01 count=0x02 status=0x50 (g-io-error-quark, 0)
pulseaudio[953]: X11 I/O error handler called
pulseaudio[953]: X11 I/O error exit handler called, preparing to tear down X11 modules
systemd[936]: xfce4-notifyd.service: Main process exited, code=exited, status=1/FAILURE
systemd[936]: xfce4-notifyd.service: Failed with result 'exit-code'.
kernel: button: module verification failed: signature and/or required key missing - tainting kernel
input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2
piix4_smbus 0000:00:07.3: SMBus Host Controller not enabled!
sd 2:0:0:0: [sda] 167772160 512-byte logical blocks: (85.9 GB/80.0 GiB)
kernel: sd 2:0:0:0: [sda] Write Protect is off
kernel: sd 2:0:0:0: [sda] Mode Sense: 61 00 00 00
kernel: sd 2:0:0:0: [sda] Cache data unavailable
kernel: sd 2:0:0:0: [sda] Assuming drive cache: write through
systemd[1]: File System Check on Root Device was skipped because of a failed condition check (ConditionPathExists=!/run/initramfs/fsck-root).
systemd[1]: Starting Journal Service...
systemd[1]: Starting Load Kernel Modules...
kernel: fuse: init (API version 7.34)
systemd[1]: Starting Remount Root and Kernel File Systems...
systemd[1]: Repartition Root Disk was skipped because all trigger condition checks failed.
systemd[1]: Starting Coldplug All udev Devices...
systemd[1]: Mounted Huge Pages File System.
systemd[1]: Mounted POSIX Message Queue File System.
systemd[1]: Mounted Kernel Debug File System.
kernel: EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro. Quota mode: none.

fsck 的輸出顯示了幾種類型的更正錯誤：

• 刪除的 inode 的 dtime 為零：這是一個可能已打開但在系統崩潰時被刪除的文件。（有時這些被標記為“孤立”文件。）它通常在關閉之前不會被真正刪除；這樣 fsck 就完成了刪除操作。（這是系統崩潰後非常典型的問題。）
• 發現損壞的孤立鍊錶：保留部分刪除文件的列表，以便以後更容易清理；顯然，該列表已損壞，可能是由於部分寫入了該列表。修復此問題應該沒有腐敗。
• 空閒塊計數錯誤：有塊不屬於任何不在空閒列表中的文件的一部分。可能是上述刪除的副作用。
• Inode 點陣圖差異/空閒 inode 計數錯誤：有空閒 inode 未標記為空閒（上述修復的副作用）

因此 fsck 所做的更改不會損壞任何文件。

但是，令人擔憂的是，您的文件系統最初是只讀的。這可能是由於核心檢測到記憶體損壞或磁碟在使用時完全或部分離線造成的。

如果在寫入文件時出現硬體錯誤，則可能是文件損壞。如果磁碟在寫入過程中離線，則可能存在部分寫入的文件或已創建但從未寫入磁碟並且現在完全失去的文件。

所以，直接回答你的觀點：

• 您可以信任 fsck 修復過程。列出的消息都是相當良性的修復。
• 您可以使用類似find / -type f -mtime -1查找在最後一天修改的文件並查看其中是否有任何被截斷的方法，或者使用您對系統當時正在執行的操作的了解來查看使用中的任何內容是否未完全寫入。
• 尋找失去的文件很棘手，但如果有什麼重要的東西失去了，我相信你會注意到的。
• 要了解這一點的全部後果，您需要確定導致文件系統變為只讀的根本原因。只有這樣才能猜出全部傷害。

引用自：https://unix.stackexchange.com/questions/700182