This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 477942 - fsck clears orphan inodes instead of linking into lost+found
fsck clears orphan inodes instead of linking into lost+found
Product: Fedora
Classification: Fedora
Component: e2fsprogs (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Eric Sandeen
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-12-25 22:33 EST by G.Wolfe Woodbury
Modified: 2008-12-27 22:27 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-12-27 12:58:40 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 G.Wolfe Woodbury 2008-12-25 22:33:19 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:

Steps to Reproduce:
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).
Comment 1 Eric Sandeen 2008-12-26 12:16:07 EST
please provide a log of the fsck run so I can see exactly what it is doing.

Comment 2 G.Wolfe Woodbury 2008-12-27 01:21:42 EST
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!
Comment 3 Eric Sandeen 2008-12-27 12:58:40 EST
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.

Comment 4 Eric Sandeen 2008-12-27 22:27:27 EST
Just to be sure, was it something like:

Clearing orphan inode 12345 (uid=XXX, gid=XXX, mode=XXX, size=XXX) ?

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