I have a VM running ubuntu LTS with an ext4 filesystem. We had performance problems that were related to IO tasks. I checked the filesystem with

fsck.ext4 -nv /dev/sda1 e2fsck 1.41.11 (14-Mar-2010)

Warning! /dev/sda1 is mounted.

Warning: skipping journal recovery because doing a read-only filesystem check.

/dev/sda1 contains a file system with errors, check forced.

Pass 1: Checking inodes, blocks, and sizes

Pass 2: Checking directory structure

Entry 'pgstat.stat' in /var/lib/postgresql/8.4/main/pg_stat_tmp (4721210) has deleted/unused inode 4732417. Clear? no

Pass 3: Checking directory connectivity

Pass 4: Checking reference counts

Unattached zero-length inode 2127051. Clear? no

Unattached inode 2127051

Connect to /lost+found? no

Unattached inode 4757639

Connect to /lost+found? no

Pass 5: Checking group summary information

Block bitmap differences: -(1977109--1977118) -5190038 -7050074 -8435151 +8435477 -11906565 -(12532266--12532267) +13664464 +13664508 -13665161 +(13667660--13667674) -(13667675--13667729) -13669860 +(13671792--13671831) -(15571824--15571832) -(15582843--15582846) -16292177 -(16711922--16711928) -19144303 +19689076 -(22516788--22517441) -22635570 -(22974110--22974111) -(23736402--23736403) +(23956398--23957051) -24092764 -24832492

Fix? no

while the machine was still running (-n), it reported a couples of failures, so we called the hoster of the VM to shut it down and do an fsck with the unmounted disk. The hoster said there are no FS errors reported by fsck, he attached an screenshot.

As the VM was up again, I repeated the fsck and got the same results.

Do the results differ because the filesystem is still mounted and is kind of "inconsistent"?


The answer is YES. fsck assumes an unmounted, unchanging disk and that it has full control of the disk.

There are several passes that fsck uses, and these feed into each other, with the disk changing all the time, it is LIKELY that false errors are going to be registered.

I'm curious as to what information you feel you are getting by fsck'ing an active disk?


You can use the free Hot Copy utility to snapshot and fsck a mounted filesystem to see if it really needs repair. You should NOT fsck an already mounted system in the manner you did.

hcp --skip-mount /dev/sda1
fsck -a -y /dev/hcp1

Please see: Unable to list contents/remove directory (linux ext3)

My guess is that you don't need repair at all. There are a world of issues that could result in poor I/O, though, spanning kernel scheduling algorithms to failing disks to lack of a quality RAID controller with write cache.

Can you provide more information about your setup?

  • Thanks for the tool tip, the fsck did run with the -n flag on the mounted disk so no changes are made, turned out the performance problem was a problem with the storage of the hoster. – Izac Nov 21 '12 at 0:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.