Bug 477942

Summary: fsck clears orphan inodes instead of linking into lost+found
Product: [Fedora] Fedora Reporter: G.Wolfe Woodbury <redwolfe>
Component: e2fsprogsAssignee: Eric Sandeen <esandeen>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 10CC: esandeen, kzak, oliver
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-12-27 17:58:40 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description G.Wolfe Woodbury 2008-12-26 03:33:19 UTC 
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).
Comment 1 Eric Sandeen 2008-12-26 17:16:07 UTC 
please provide a log of the fsck run so I can see exactly what it is doing.

Thanks,
-Eric
Comment 2 G.Wolfe Woodbury 2008-12-27 06:21:42 UTC 
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 17:58:40 UTC 
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
Comment 4 Eric Sandeen 2008-12-28 03:27:27 UTC 
Just to be sure, was it something like:

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