文件系统损坏时需用fsck修复，但必须在未挂载状态下操作，尤其是根文件系统应通过Live CD或恢复模式处理，避免数据丢失。
文件系统损坏在Linux环境中并不少见，无论是意外断电、硬件故障还是软件错误，都可能导致文件系统出现不一致。幸运的是，Linux提供了一个强大的工具——
fsck
（file system check），它能帮助我们诊断并修复这些问题。简单来说，
fsck
就是你处理文件系统“健康问题”时的首选医生，它通过检查文件系统结构，找出并尝试修复其中的错误，确保你的数据能够被系统正常访问。
解决方案
要修复Linux中的文件系统，核心工具就是
fsck
。然而，使用它有一个黄金法则：永远不要在已挂载的文件系统上运行
fsck
。这就像你不能在汽车高速行驶时更换轮胎一样，那样只会导致更严重的损坏，甚至数据丢失。
在运行
fsck
之前，你需要：
识别目标文件系统：使用
lsblk
或
df -h
命令来找出你想要检查的磁盘分区（例如
/dev/sda1
,
/dev/sdb2
）。
lsblk -f
这个命令会显示所有块设备及其文件系统类型和挂载点，这对于定位非常有用。
卸载目标文件系统：如果分区是独立的（非根文件系统），使用
umount
命令将其卸载。
sudo umount /dev/sdXN
将
sdXN
替换为你的实际分区名，比如
/dev/sdb1
。如果系统提示设备忙碌，你可以尝试终止占用该分区的进程，或者在单用户模式/Live CD环境中操作。
运行
fsck
：一旦文件系统被卸载，你就可以安全地运行
fsck
了。
sudo fsck -f /dev/sdXN
这里的
-f
选项强制
fsck
检查文件系统，即使它看起来是“干净”的。如果希望
fsck
自动修复所有发现的问题而无需交互，可以加上
-y
选项（即对所有问题都回答“yes”）：
sudo fsck -fy /dev/sdXN
或者，使用
-a
选项进行自动修复，它比
-y
更保守，只修复那些被认为是安全的问题。
sudo fsck -fa /dev/sdXN
fsck
实际上是一个前端程序，它会根据文件系统的类型（如ext2/3/4、XFS、Btrfs等）调用对应的文件系统检查工具（例如
fsck.ext4
、
xfs_repair
）。所以，你通常不需要指定具体的工具，
fsck
会帮你搞定。
哪些迹象表明文件系统可能损坏，需要运行
fsck
检查？
在我的经验里，文件系统损坏的信号往往很明显，但有时也相当微妙。最直接的，莫过于系统启动时屏幕上滚动的一堆错误信息，比如“Input/output error”或者“UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY”。这基本上是系统在明确告诉你：“嘿，我的文件系统有点不对劲，快来帮我看看！”
除了这些赤裸裸的报错，还有一些迹象也值得注意：
黑点工具
在线工具导航网站，免费使用无需注册，快速使用无门槛。
18 查看详情 系统性能急剧下降：平时运行流畅的系统突然变得异常缓慢，打开文件、执行命令都卡顿不已。这可能意味着文件系统在读取或写入数据时遇到了障碍。文件丢失或内容损坏：你明明保存了一个文件，过了一会儿却找不到了，或者打开后发现内容乱码、不完整。这通常是文件系统元数据（比如文件分配表）出了问题。无法挂载分区：尝试挂载一个分区时，系统报错说无法挂载，或者提示文件系统类型未知，甚至干脆说文件系统损坏。应用程序频繁崩溃：特别是那些需要大量读写磁盘数据的应用，如果它们无缘无故地频繁崩溃，文件系统层面的问题可能是幕后黑手。意外关机或断电后：这是最常见的原因之一。如果你遇到过突然的断电，或者因为系统卡死而被迫长按电源键关机，那么文件系统很可能没有被正常卸载，留下了“脏位”（dirty bit），下次启动时，系统通常会自动触发
fsck
检查，但有时可能需要手动介入。
我记得有一次，我的开发服务器在一次停电后启动异常，虽然还能进入系统，但很多服务都无法启动，
dmesg
里充斥着ext4的错误信息。那时候，手动进入恢复模式，对根分区运行
fsck -fy
，就成了唯一的救命稻草。
如何安全地运行
fsck
，特别是针对根文件系统？
安全运行
fsck
的核心原则就是“未挂载”。对于非根文件系统，这相对简单，直接
umount
即可。但对于根文件系统（
/
），它在系统运行时是必须挂载的，这就需要一些特别的技巧。
对于非根分区（例如数据盘、独立的用户分区）：这是最直接的情况。假设你的数据盘是
/dev/sdb1
，并且挂载在
/mnt/data
。
sudo umount /mnt/data# 或者直接针对设备路径卸载sudo umount /dev/sdb1sudo fsck -fy /dev/sdb1
如果
umount
失败，提示设备忙碌，你可以使用
lsof | grep /mnt/data
来查看哪些进程正在使用它，然后终止这些进程。或者，更彻底的做法是重启到单用户模式或Live CD。
对于根文件系统（
/
）：这是最需要小心的地方，因为你不能直接在运行中的根文件系统上卸载并运行
fsck
。
方法一：通过Live CD/USB启动这是最安全也最推荐的方法。
准备一张Live Linux发行版（如Ubuntu Live CD/USB）。从Live CD/USB启动你的电脑。打开终端。使用
lsblk -f
或
sudo fdisk -l
命令识别你的根分区（通常是
/dev/sdaX
或
/dev/nvme0n1pX
）。确保目标分区没有被Live系统自动挂载。如果挂载了，先
sudo umount /dev/sdXN
。运行
fsck
命令：
sudo fsck -fy /dev/sdXN
将
sdXN
替换为你的实际根分区。
修复完成后，重启系统并移除Live CD/USB。
方法二：进入恢复模式（Recovery Mode）或单用户模式大多数Linux发行版都提供了恢复模式，它通常会以只读方式挂载根文件系统，或者提供一个shell环境让你手动操作。
重启电脑，在GRUB启动菜单出现时，选择“Advanced options for Ubuntu”（或其他发行版），然后选择带有“(recovery mode)”字样的选项。进入恢复菜单后，选择“fsck”选项，系统会自动尝试修复文件系统。如果选择“Drop to root shell prompt”，你将获得一个root权限的shell。此时，根文件系统通常是只读挂载的。你需要先将其以读写方式重新挂载，或者在某些情况下，它可能已经允许你直接运行
fsck
。如果需要手动操作，通常会是这样：
mount -o remount,rw /# 此时，根文件系统是可写的，但仍然是挂载状态。# 为了安全，更好的做法是让fsck在下次启动时运行。# 或者，如果fsck允许在只读模式下检查，它会提示你是否需要reboot来完成修复。# 更安全的做法是：# 先确保根目录是只读挂载mount -o remount,ro /# 然后运行fsckfsck -fy /dev/sdXN# fsck可能会提示需要重启来完成修复，按照提示操作。
请注意，在单用户模式下对根文件系统执行
fsck
需要非常谨慎，因为即使是只读挂载，也可能因为
fsck
内部的某些操作而导致问题。Live CD/USB方法是更稳妥的选择。
我个人在处理根文件系统损坏时，总是倾向于Live CD/USB。它提供了一个完全独立、干净的环境，避免了在“自举”过程中可能遇到的各种复杂问题。虽然多了一步制作启动盘，但换来的是安心和更高的成功率。
运行
fsck
时可能遇到的常见问题及解决方案是什么？
在使用
fsck
的过程中，确实会遇到一些让人头疼的问题。了解这些问题以及如何应对，能让你在关键时刻不至于手足无措。
“File system is mounted” 错误：这是最常见的错误，意味着你尝试在已挂载的分区上运行
fsck
。
解决方案：对于非根分区：先
sudo umount /dev/sdXN
。如果无法卸载，可能是某个进程正在使用它。使用
lsof | grep /dev/sdXN
找出并终止相关进程，或者直接重启到Live CD/USB环境。对于根文件系统：如前所述，通过Live CD/USB启动，或者进入恢复模式。
fsck
报告大量错误，并反复询问“Fix?”：当文件系统有严重损坏时，
fsck
会逐个列出发现的问题，并询问你是否修复。手动确认会非常耗时。
解决方案：使用
-y
选项 (
sudo fsck -fy /dev/sdXN
)，让
fsck
自动对所有问题回答“yes”。这通常是推荐的做法，但请注意，它可能会导致一些数据丢失（例如，将无法恢复的文件块移动到
lost+found
目录）。使用
-a
选项 (
sudo fsck -fa /dev/sdXN
)，进行自动修复。它比
-y
更保守，只修复那些被认为是安全的问题。
fsck
运行时间过长，甚至看起来像是卡住了：对于非常大的分区或者损坏严重的文件系统，
fsck
可能需要很长时间才能完成。
解决方案：耐心等待：在许多情况下，它只是在默默工作。你可以通过查看磁盘活动指示灯（如果有的话）或者通过
dmesg
命令查看是否有新的内核日志输出来判断它是否还在运行。检查磁盘健康状况：如果等待很久依然没有进展，可能不是文件系统损坏，而是硬盘本身存在物理坏道。此时，你可以使用
smartctl
工具（
sudo smartctl -a /dev/sdX
）来检查硬盘的S.M.A.R.T.信息，看看是否有硬件故障的迹象。如果是硬盘物理损坏，
fsck
也无能为力，你需要考虑更换硬盘并从备份中恢复数据。
fsck
报告“dirty bit”已设置，但文件系统似乎没有问题：“dirty bit”是一个标记，表示文件系统在上次卸载时没有被正确关闭（例如，意外断电）。系统通常会在启动时自动检测并清除它。
解决方案：通常情况下，
fsck
会自动清除这个位。如果它提示你手动运行
fsck
，即使你认为文件系统没问题，也最好运行一次
fsck -f
来确保所有元数据都已同步。这就像是给文件系统做一次例行体检。
fsck
修复后，部分文件丢失或被移动到
lost+found
目录：
fsck
的主要目标是恢复文件系统的结构完整性，而不是保证所有文件的完整性。当它发现无法与任何目录条目关联的孤立数据块时，会将其视为文件并移动到分区根目录下的
lost+found
目录。
解决方案：进入
lost+found
目录 (
cd /lost+found
)，你会看到一些名为
#
的文件或目录。这些就是
fsck
找回来的“孤儿”。你可以尝试使用
file
命令 (
file #12345
) 来猜测这些文件的类型（例如，文本文件、图片、二进制文件），然后尝试重命名并打开它们，看看是否包含你需要的数据。这需要一些耐心和运气，但有时能挽救一些重要文件。
我个人就遇到过一次，因为忘记
-y
选项，结果
fsck
针对一个损坏严重的U盘，不断地问我是否修复inode、数据块等等，简直是噩梦。后来学乖了，重要数据先备份，然后
-fy
一把梭。当然，前提是确认这不是物理损坏，否则再怎么
fsck
也是徒劳。
以上就是如何在Linux中修复文件系统 Linux fsck工具使用指南的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/439210.html
微信扫一扫 
支付宝扫一扫 
