☰

Ubuntu 服务器：无法删除文件“x”，结构需要清理

tag-icon • tag-icon linux ubuntu ext2
Ubuntu 服务器：无法删除文件“x”，结构需要清理

我在 Ubuntu Server 16.04 上托管了一个游戏服务器，由于以下文件，我突然无法启动/重新启动它：

-????????? ? ?     ?        ?            ? proceduralmap.3000.1499245715.149.sav

这似乎是 fs 中唯一一个出现这种情况的文件。现在，该服务器是从托管服务提供商处购买的专用服务器。文件所在的驱动器是 SCSI 挂载的 HDD（/dev/sdb1）。

输出df -hT：

Filesystem     Type      Size  Used Avail Use% Mounted on
udev           devtmpfs  3.7G     0  3.7G   0% /dev
tmpfs          tmpfs     744M   81M  663M  11% /run
/dev/sda4      ext4       21G   16G  4.7G  77% /
tmpfs          tmpfs     3.7G   24K  3.7G   1% /dev/shm
tmpfs          tmpfs     5.0M     0  5.0M   0% /run/lock
tmpfs          tmpfs     3.7G     0  3.7G   0% /sys/fs/cgroup
/dev/sda3      ext4      946M  143M  739M  17% /boot
cgmfs          tmpfs     100K     0  100K   0% /run/cgmanager/fs
/dev/sdb1      ext2      985G  265G  670G  29% /storage
tmpfs          tmpfs     744M     0  744M   0% /run/user/1011

修复/删除该文件的适当方法是什么？我更愿意修复它，但删除它也可以。我已经运行了：

debugfs -w /dev/sdb1

我输入的内容：

clri home/steam/serverfiles/server/rustserver/proceduralmap.3000.1499245715.149.sav

从网上找到的信息来看，我知道我需要运行 e2fsck，但我也知道我需要先卸载驱动器。如果可能的话，我不想只为这个文件这样做。

谢谢！

答案1

“结构需要清除”错误消息是怎么回事

“结构需要清除”错误是文件系统（特别是 ext4 和 xfs）在检测到文件系统损坏问题时返回的错误。不幸的是，修复损坏的唯一安全方法是卸载磁盘并e2fsck在文件系统上运行。（从技术上讲，您不需要该-f选项，因为文件系统已经检测到问题并将文件系统标记为有问题。因此，当您运行时，e2fsck它将进行全面扫描以修复这些问题，您不需要-f强制检查的选项。）

文件系统损坏报告

您还应该能够通过查看内核日志来查看文件系统损坏的报告。（例如，通过运行dmesg，或者查看/var/log/kern.log或任何您的syslog或journald已配置为记录内核消息的地方。您应该看到以 开头的消息EXT4-fs error (device sdXX)。例如：

EXT4-fs error (device sda3): ext4_lookup:1602: inode #37005: comm docker: deleted inode referenced: 31872136

dumpe2fs -h您还可以通过查看文件系统来查看错误迹象。感兴趣的字段：

FS Error count:           25

这意味着内核已经 25 次发现文件系统不一致。

First error time:         Thu Jan  1 12:19:59 2015
First error function:     ext4_ext_find_extent
First error line #:       400
First error inode #:      95223833
First error block #:      0

第一个错误是在 2015 年 1 月 1 日的指定时间发现的。错误函数和行号允许您准确识别内核代码的哪个部分发现了问题。inode # 告诉您哪个 inode 与文件系统不一致有关。

Last error time:          Wed Feb  4 11:57:05 2015
Last error function:      ext4_ext_find_extent
Last error line #:        400
Last error inode #:       95223833
Last error block #:       0

这告诉您内核最近一次发现文件系统不一致的时间。两次之间的巨大差异意味着某人没有扫描其内核消息。这是因为每 24 小时，ext4 都会记录警告消息，指出文件系统存在损坏，这些内核消息将如下所示：

EXT4-fs (dm-0): error count since last fsck: 12
EXT4-fs (dm-0): initial error at time 1441536566: ext4_dirty_inode:4655
EXT4-fs (dm-0): last error at time 1441537273: ext4_remount:4550

注意：内核消息中的时间是自 1970 年 1 月 1 日午夜 UTC 以来的秒数。您可以使用 date 命令将其转换为更人性化的时间，例如：

% date -d @1441536566
Sun Sep  6 06:49:26 EDT 2015

当你意识到文件系统已损坏时该怎么办

您确实不想在文件系统不一致的情况下运行，因为这会导致更多数据丢失。最好立即查看这些报告，必要时安排停机时间，并尽快修复它们。

为什么e2fsck我卸载设备后却提示该设备正在使用中？

最后，回答您的问题：“fsck卸载后我运行并收到以下错误：/dev/sdb1 is in use.有什么想法吗？” 这可能是因为您在备用挂载命名空间中有一个或多个进程，并且这些进程仍挂载/dev/sdb1在该挂载命名空间中。您可能想尝试：

grep /dev/sdb1 /proc/*/mounts

如果您发现进程在备用挂载命名空间中运行，最简单的做法是终止并重新启动这些进程。（它们可能是守护进程。）当使用挂载命名空间的最后一个进程退出时，挂载命名空间就会消失。一旦没有挂载的挂载命名空间/dev/sdb1，它就会真正被卸载。

思考这个问题的方法是，它的umount作用类似于unlink。如果您有一个包含多个硬链接的文件，则只有在删除最后一个硬链接时才会释放空间。如果您有多个活动命名空间，则每个命名空间实际上都充当了相关挂载的“硬链接”。因此，如果某个进程已经分叉了默认挂载命名空间，并且正在其父挂载命名空间的写时复制副本中运行自身和可能的一些子进程，那么仅在默认挂载命名空间中卸载文件系统将无济于事。

相关内容