Bug 161532 - Unnecessary manual fsck after crash?
Unnecessary manual fsck after crash?
Product: Fedora
Classification: Fedora
Component: e2fsprogs (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Eric Sandeen
Depends On:
  Show dependency treegraph
Reported: 2005-06-23 20:11 EDT by John Robinson
Modified: 2008-02-11 19:35 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-11 19:35:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description John Robinson 2005-06-23 20:11:14 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Description of problem:
Recently my system has been crashing a lot, due I think to a hardware bug, but that's not the point. When it restarts, and I say 'Y' to fsck'ing (or indeed have /etc/sysconfig/autofsck set suitably), I get messages like the following (copied from the screen on the crashing PC):
/dev/out/var: Clearing orphaned inode 339378 (uid=0, gid=0, mode=020600, size=0)
/dev/out/var: Clearing orphaned inode 339375 (uid=0, gid=0, mode=020600, size=0)
Extended attribute block 1212926 has reference count 63, should be 61


This is an ext3 filesystem over lvm, as all my filesystems are. Since my system has crashed a lot recently, I've noticed that the number of "clearing orphaned inode" messages always corresponds exactly with the difference between the reference counts stated. I suspect that if autofsck can clear orphaned inodes itself (I think it used to be able to with ext2) then it ought to be able to update the corresponding reference count, and I might be saved a manual fsck and another reboot and fsck. I'm not sure whether this is an initscripts error or an e2fsprogs error, or even whether I'm right in thinking there's a problem...

Version-Release number of selected component (if applicable):
initscripts-7.93.7-1 e2fsprogs-1.36-1.FC3.1

How reproducible:

Steps to Reproduce:
1.Crash system
4.Do mental arithmetic

Actual Results:  fsck always says "UNEXPECTED INCONSISTENCY"

Expected Results:  ext3's great; surely sometimes the filesystem could be recovered automatically...?

Additional info:
Comment 1 Bill Nottingham 2005-06-23 23:19:12 EDT
Actually, e2fsprogs is probably better than kernel; changing.
Comment 2 Stephen Tweedie 2005-06-24 05:15:40 EDT
What's the kernel version?  The EA refcount mismatch is consistent with a
problem in the original FC3 kernel which is fixed in recent versions.
Comment 3 John Robinson 2005-06-24 06:31:42 EDT
Hi Stephen. I've been seeing this behaviour with 2.6.10-1.770_FC3 and
Comment 4 Matthew Miller 2006-07-10 18:27:13 EDT
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!
Comment 5 petrosyan 2008-02-11 19:35:44 EST
Fedora Core 3 is not maintained anymore.

Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the
current Fedora release, please reopen this bug and assign it to the
corresponding Fedora version.

Note You need to log in before you can comment on or make changes to this bug.