Clearing orphaned inode

转载: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为系统恢复时的正常操作

其是清理上次系统不正常关闭时，那么在磁盘但是已经不可达的文件。

而这些文件产生的一个原因，如一个进程打开一个文件，

但是这个文件被更新或者删除了，这时候旧的文件虽然不可达了，但是

磁盘不会马上清理它，而是等到最后一个还引用这个文件的用户／进程退出后，

便会清理这个文件。但是如果这个时候系统宕机或者不正确关闭了。

这时候这个不可达文件仍然在系统中，这时候系统恢复的时候，发现这类文件，

便会重新清理这些文件