fsck seems to show different result between multi user mode and single user mode

Question

I'm using CentOS6.7 as a guest OS with vagrant and virtual box;

the background of the question

the terminal emulator frequently got flozen after I did login by vagrant ssh to CentOS today. I haven't encountered such things before.

After some examination, I found two things.

1. the guest OS's bootup took very longer time than yesterday.
2. the root file system looked to have some problems.

I saw the following by executing 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)

And this was /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

So I shutdown the guest OS then booted it again with single user mode. After that, I did like bellow.

# umount /
# fsck /dev/mapper/VolGroup-vl_root

But the result was like this.

/dev/mapper/VolGroup-lv_root clean ...

I tried fsck with other options for file system checking.

# 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
...
...

Question

Is it possible that fsck tells different result between multi user mode and single user mode??

I think, fsck clearly told the root file system has some troubles at first time. But it seemed to show there was no problem at second and third time.

Are there any methods or practices to solve problems like this in common?

Answer 1

Never fsck a filesystem while it is mounted. First, it will always be marked dirty - the process of mounting itself sets the "filesystem dirty" flag, and that flag is normally unset at umount. Second, if fsck starts making changed to a mounted filesystem, especially /, you may end up with worse problems that you thought you had when things really go haywire because something is diddling bits out from underneath running programs.

So to answer your question, yes, fsck will always give you different results for mounted and unmounted filesystems. Mostly because you shouldn't be running it against mounted filesystems.

(Note: this is only really applicably to the ext2/3/4 filesystems - XFS and ReiserFS (for example) are totally different beasts.)