From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 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 messages were: ----- /home2: recovering journal /home2: Clearing orphaned inode 2768994 (uid=500, gid=599, mode=0100600, size=33828864) /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 sparse_super large_file 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): e2fsprogs-1.32-6 How reproducible: Didn't try 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 directory. Additional info:
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.