Red Hat Bugzilla – Bug 147748
data loss: Clearing orphaned inode
Last modified: 2007-11-30 17:11:00 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Description of problem:
During a reboot to multiuser runlevel 5 after a hang, a 33MB file was
lost. It was time for fsck based on mount count. The text console
/home2: recovering journal
/home2: Clearing orphaned inode 2768994 (uid=500, gid=599,
/home2 has been mounted 27 times without being checked, check forced.
Indeed, the file is now nowhere to be found, not even in the
/lost+found directory, which exists (and did exist) with a size of
16384 bytes. So it looks to me like "recovering journal" zapped the
file, and forgot about the possibility of re-parenting it into
/lost+found . I'm very disappointed.
/sbin/tune2fs -l /dev/hdb8 [the relevant partition] says:
tune2fs 1.35 (28-Feb-2004)
Filesystem volume name: /home2
Last mounted on: <not available>
Filesystem UUID: 41351c20-ec75-4262-8e08-bd6fc324f4a7
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr filetype needs_recovery
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 20168704
Block count: 40331174
Reserved block count: 2016558
Free blocks: 19567225
Free inodes: 19023638
First block: 0
Block size: 4096
Fragment size: 4096
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16384
Inode blocks per group: 512
Filesystem created: Sat Mar 13 11:50:28 2004
Last mount time: Thu Feb 10 13:40:45 2005
Last write time: Thu Feb 10 13:40:45 2005
Mount count: 2
Maximum mount count: 27
Last checked: Thu Feb 10 12:13:39 2005
Check interval: 15552000 (6 months)
Next check after: Tue Aug 9 13:13:39 2005
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: 1b80d5cc-d9dd-49a7-b106-afe3819dc7ed
Journal backup: inode blocks
The [data-losing] recovery took place on a RedHat 9 system with
e2fsprogs-1.32-6. Please check to see that such data loss cannot
happen with the relevant current version, which I believe to be
e2fsprogs-1.35-11.2. In otherwords, "Clearing orphaned inode" should
never occur unless /lost+found has no available entries.
Unfortunately, "strings /sbin/e2fsck" suggests that there could still
be a problem: both "Clearing" and "orphaned" appear.
Version-Release number of selected component (if applicable):
Actual Results: Data loss: "orphaned" file was deleted, even though
/lost+found was 16384 bytes and contained no files.
Expected Results: Any file which has been orphaned should be placed
into /lost+found unless there are no more available slots in that
This is not a bug, it's the journaling clearing up a normal situation.
An "orphaned" inode in this context is one which has been explicitly
deleted, but which was still open by some process when it was deleted.
The file vanishes completely from the directory structure, but normal
Unix semantics require it to remain present on disk until the last
user of that file closes it. At that point, the inode itself (as
opposed to the directory entries pointing to it) is deleted, and the
disk space used by the file is cleaned up.
Now, if such an orphaned file is present when we crash or forcibly
reboot/shutdown, then the reboot counts as a "close" of the file,
because it is obviously no longer open! But the inode is still
present on disk, because it was open when the system rebooted.
In that case it is perfectly legal for ext3 to delete the inode during
its recovery, because the file has already been explicitly deleted
during previous operations.
This happens all the time when, for example, an rpm upgrade of system
libraries is done. The old libraries may still be in use by running
applications, but the rpm upgrade will delete the files. The expected
behaviour is that the old files are gone after a reboot, with no disk
space leaking to the previously-in-use inodes. So the inode delete is
required. It would be a bug if this situation lead to
properly-deleted inodes coming back from the dead into /lost+found.