Red Hat Bugzilla – Bug 477942
fsck clears orphan inodes instead of linking into lost+found
Last modified: 2008-12-27 22:27:27 EST
Description of problem: in all the current versions of Fedora, the boot time fsck clears orphan inodes instead of linking them to lost+found. Version-Release number of selected component (if applicable): How reproducible: consistently Steps to Reproduce: 1. 2. 3. Actual results: the fsck reports clearing of orphan inodes Expected results: fsck should link the orphans into lost+found Additional info: lost+found exists on the filesystems in question. examination of the man pages reveal no options that seem to affect this malbehaviour. This is on at least three systems (F9,F10,rawhide) but is especially noticed on the rawhide box as it is subject to occasional crashes. So far no system-critical files are known to be affected, but that cannot be verified since there is no evidence of what files are actually deleted. They are found on / and /usr filesystems in general and lost+found is verified to be present and populated (as make by the mkfs process).
please provide a log of the fsck run so I can see exactly what it is doing. Thanks, -Eric
There are no logs *per se* since they take place during the system bootup process. One can, fairly easly (but dangerously) reproduce the problem by powering down the system without shutting down first. basically, the autofsck reports that orphan inodes are found (typically in /usr filesystem) and report that they have been cleared. They are *not* zero-lenght files, but they are cleared instead of linked to lost+found. I've seen this F8 and have been wondering why we bother with lost+found at all if the systems isn't going to use it!
Orphan inodes *should* be cleared; these were files that were unlinked while they were open, and then a crash happened. Deleting them on the next boot is exactly what should happen, it completes the unlinking that would have happened when the last user closed the file post-unlink. Also, lost+found is not a junkbox for corrupted inodes, it is specifically for inodes which have lost their parent link. If fsck doesn't find such inodes, it won't populate lost+found. This is why I asked for the details of the fsck run, I need to see what it's doing and why to determine if it's doing anything wrong. But if they are truly orphan inodes then clearing them is exactly right. I'm going to NOTABUG this, based on your description of what is happening. Thanks, -Eric
Just to be sure, was it something like: Clearing orphan inode 12345 (uid=XXX, gid=XXX, mode=XXX, size=XXX) ?