转载:https://bugzilla.redhat.com/show_bug.cgi?id=147748
Clearing orphaned inode:
Stephen Tweedie
2005-02-10 18:35:23 EST
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.按照回答者的描述:
clearing orphaned inode为系统恢复时的正常操作
其是清理上次系统不正常关闭时,那么在磁盘但是已经不可达的文件。
而这些文件产生的一个原因,如一个进程打开一个文件,
但是这个文件被更新或者删除了,这时候旧的文件虽然不可达了,但是
磁盘不会马上清理它,而是等到最后一个还引用这个文件的用户/进程退出后,
便会清理这个文件。但是如果这个时候系统宕机或者不正确关闭了。
这时候这个不可达文件仍然在系统中,这时候系统恢复的时候,发现这类文件,
便会重新清理这些文件