我使用 CentOS6.7 作为带有 vagrant 和 virtual box 的来宾操作系统;
问题的背景
vagrant ssh
今天登录CentOS后,终端模拟器经常卡住。我以前没有遇到过这样的事情。
经过一番检查,我发现了两件事。
- 客户操作系统的启动时间比昨天要长得多。
- 根文件系统看起来有一些问题。
我通过执行 fsck 看到以下内容。
$ fsck -n
/dev/mapper/VolGroup-lv_root contains a file system with errors, check forced.
...
...
Free blocks count wrong (845378, counted=845408)
Free inodes count wrong (309812, counted=309769)
这是 /etc/fstab:
$ cat /etc/fstab
/dev/mapper/VolGroup-lv_root / ext4 defaults 1 1
UUID=d197cae3-0dd5-4555-9b2f-f9f21c1d9679 /boot ext4 defaults 1 2
/dev/mapper/VolGroup-lv_swap swap swap defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
因此,我关闭了来宾操作系统,然后以单用户模式再次启动它。在那之后,我确实喜欢吼叫。
# umount /
# fsck /dev/mapper/VolGroup-vl_root
但结果却是这样的。
/dev/mapper/VolGroup-lv_root clean ...
我尝试使用 fsck 和其他选项来检查文件系统。
# fsck -fv -t ext4 /dev/mapper/VolGroup-lv_root
fsck from util-linux-ng 2.17.2
pass 1: checking ...
...
...
pass 5: group summary information
130829 inodes used
...
...
913928 blocks used
0 bad blocks
1 large file
...
...
问题
fsck 是否有可能在多用户模式和单用户模式之间给出不同的结果?
我想,fsck第一时间就明确告诉根文件系统出现了一些问题。但第二次、第三次似乎就没有问题了。
有没有一些共同的方法或做法来解决此类问题?
答案1
切勿在安装文件系统时对其进行 fsck。首先,它总是被标记为脏——安装过程本身设置了“文件系统脏”标志,并且该标志通常在卸载时取消设置。其次,如果 fsck 开始对已安装的文件系统进行更改,尤其是/
,当事情真正变得混乱时,您可能会遇到更糟糕的问题,因为某些东西正在从正在运行的程序中窃取位。
因此,要回答您的问题,是的,fsck
对于已安装和未安装的文件系统,总会给出不同的结果。主要是因为您不应该针对已安装的文件系统运行它。
(注意:这只真正适用于 ext2/3/4 文件系统 - XFS 和 ReiserFS(例如)是完全不同的野兽。)