Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top
fsck 1.38 (30-Jun-2005)
e2fsck 1.38 (30-Jun-2005)
Warning!  /dev/vgname/lvname is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/vgname/lvname contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Inode 12845121 ref count is 1, should be 2.  Fix? no

Inode 12845122 ref count is 1, should be 2.  Fix? no

Inode 12845123 ref count is 1, should be 2.  Fix? no

Inode 12845124 ref count is 1, should be 2.  Fix? no

Pass 5: Checking group summary information
Free blocks count wrong (38829073, counted=37828469).
Fix? no

Free inodes count wrong (22658484, counted=22658235).
Fix? no

/dev/vgname/lvname: ********** WARNING: Filesystem still has errors **********

/dev/vgname/lvname: 16972/22675456 files (0.3% non-contiguous), 6521839/45350912 blocks
fsck.ext3 /dev/vgname/lvname failed (status 0x4). Run manually!

OS: SUSE LINUX Enterprise Server 9.4

FS: EXT3 with only rw options

Question: So if there is the "WARNING: Filesystem still has errors" message, I can be 100% sure that the FS has problems, and needs to be umount/fsck/mount'ed?


$ tune2fs -l /dev/vgname/lvname | grep 'Filesystem state:'
Filesystem state:         clean
share|improve this question
Check tune2fs -l /dev/vgname/lvname | grep 'Filesystem state:' – jordanm Mar 27 '13 at 14:12
I updated the q – gasko peter Mar 27 '13 at 14:27
You don't fsck a filesystem while it's mounted. Not even if it's mounted read-only. – frostschutz Mar 27 '13 at 14:48
@frostschutz fsck -n on filesystems that support it is fine on a ro mounted filesystem. – jordanm Mar 27 '13 at 14:51
You're using LVM, so at minimum, take a snapshot and fsck that. Then there will not be concurrent writes, and you can allow journal recovery. – derobert Mar 27 '13 at 15:58
up vote 5 down vote accepted

The usual advice is to not run fsck on a mounted file system . You get unreliable results - while fsck is trying to scan the file system, the kernel is still reading and writing data to it, so it will appear, to fsck, inconsistent. Some file systems allow online use of fsck, but not all - FreeBSD, for example, can check a static snapshot of a UFS2 file system while it is in use, but you still wouldn't check the file system itself while it's mounted.

The best way to check your file system is to unmount it, then run fsck on it. If it still reports problems, you can take remedial action.

share|improve this answer

If fsck(8) says a filesystem has errors (in this case, the journal could't be replayed as it was mounted read-only, for starters), it has problems. You should shut down, start in maintenance mode (add single or 1 to the kernel line when booting; or even boot with install/rescue media) and do the full fsck. Check the manual for your exact filesystem, flags to use vary. Be careful! It asks for confirmation before doing some possibly dangerous operations. Most of the time you can't do anything byt say "yes" to everything, bu read what it says/asks.

Once you get the system working, find out what messed up the filesystem. It has been literally years with ext2/3/4 that I haven't seen filesystem corruption (but I don't just pull the plug or press the Big Red Button at random either...), so it could be bad handling or failing hardware. If the disk is failing, turn the machine off and get a replacement ASAP. Failing disks usually last hours (as in "a few", not as in "some hundred") before they are gone for good. Use that time to rescue your data, later you can do the autopsy to the failing disk at leisure. If it turns out to be a false alarm, you've got yourself space for the ripped CDs ;-)

share|improve this answer
I am in the opposite boat. I have seen tons of filesystem corruption in ext3 over the past few years. Granted, these servers stayed very heavily I/O loaded and there was a large pool (3,500) that could potentially have a problem. Most of the time it was related to some kind of hardware failure. – jordanm Mar 27 '13 at 15:09
Disks which are failing due to bad blocks can last a lot longer than hours if you fix the file system on them and add the bad blocks to the filesystem list, so that those regions are not used. Obviously that's not a guarantee, and whether it's a good idea to postpone replacement indefinitely I guess depends on context, but I've had disks that remained usable for years of casual daily use after the first failure. You just have to remember to go through the whole badblocks check whenever you reformat (which is a good idea anyway). – goldilocks Mar 27 '13 at 16:02
@goldilocks, yes they can (a student had a disk that had a half dozen bad sectors for years without problems), but they usually die after a few hours to a day (years and years of experience, both with a largeish set of department computers and assorted student machines avail that). – vonbrand Mar 27 '13 at 16:11

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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