Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 161532 - Unnecessary manual fsck after crash?
Summary: Unnecessary manual fsck after crash?
Alias: None
Product: Fedora
Classification: Fedora
Component: e2fsprogs
Version: 3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Eric Sandeen
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-06-24 00:11 UTC by John Robinson
Modified: 2008-02-12 00:35 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-02-12 00:35:44 UTC

Attachments (Terms of Use)

Description John Robinson 2005-06-24 00:11:14 UTC
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-24 03:19:12 UTC
Actually, e2fsprogs is probably better than kernel; changing.

Comment 2 Stephen Tweedie 2005-06-24 09:15:40 UTC
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 10:31:42 UTC
Hi Stephen. I've been seeing this behaviour with 2.6.10-1.770_FC3 and

Comment 4 Matthew Miller 2006-07-10 22:27:13 UTC
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-12 00:35:44 UTC
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.