Bug 147748
Summary: | data loss: Clearing orphaned inode | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | John Reiser <jreiser> |
Component: | e2fsprogs | Assignee: | Thomas Woerner <twoerner> |
Status: | CLOSED NOTABUG | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 3 | CC: | sct |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-02-10 23:35:23 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
John Reiser
2005-02-10 22:11:39 UTC
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. |