当我在虚拟机上工作时，突然我意识到我的所有文件都被标记为只读。我觉得奇怪，于是我重新启动，然后提示我进入“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.
答案1
fsck 的输出显示了几种类型的已更正错误：
- 删除的 inode 的 dtime 为零：这是一个可能已打开但在系统崩溃时被删除的文件。 （有时这些文件被标记为“孤立”文件。）通常在关闭之前不会真正删除它。这样fsck就完成了删除操作。 （这是系统崩溃后非常典型的问题。）
- 发现损坏的孤立链表：保留部分删除的文件列表，以便以后更容易清理；显然这个列表已损坏，可能是由于列表的部分写入所致。解决这个问题应该不会造成腐败。
- 可用块计数错误：有些块不属于不在可用列表中的任何文件。可能是上述删除的副作用。
- 索引节点位图差异/空闲索引节点计数错误：存在未标记为空闲的空闲索引节点（上述修复的副作用）
因此 fsck 所做的更改没有损坏任何文件。
然而，令人担忧的是您的文件系统一开始就变成了只读。这可能是由于内核检测到内存损坏或磁盘在使用时完全或部分脱机所致。
如果写入文件时出现硬件错误，则文件可能会损坏。如果磁盘在写入过程中脱机，则可能存在部分写入的文件或已创建但从未写入磁盘且现在完全丢失的文件。
因此，直接回答您的观点：
- 您可以信任 fsck 修复过程。列出的消息都是相当良性的修复。
- 您可以使用诸如
find / -type f -mtime -1查找最近一天修改的文件并查看其中是否有任何文件被截断之类的方法，或者利用您对系统当时正在执行的操作的了解来查看正在使用的任何内容是否未完全写入。 - 查找丢失的文件很棘手，但如果丢失了任何重要的文件，我相信您会注意到。
- 要了解其全部后果，您需要确定导致文件系统变为只读的根本原因。只有这样才能猜测出完整的伤害。