Re: Extra per-inode data

Bill Hawes (
Fri, 30 Jan 1998 21:17:22 -0500

Martin von Loewis wrote:

> One of us is confusing issues. What exactly is an 'active hard link'?
> A hard link is a directory entry somewhere on the storage. The number
> of hard links is stored in i_nlink, and returned e.g. in stat(2).
> It is *not* related to i_count.

By an "active hard link" I mean that the dentry for hard link path exists, and
therefore has incremented i_count. The i_nlink value most certainly is "related"
to i_count, as it defines the upper bound for i_count for a file in a
well-behaved filesystem. References to objects are supposed to be added to the
dentry, so that normally i_count is the number of dentries referencing the

> So you are saying each file is removed from the disk as soon as it is
> closed? Once i_count is going to 0, the in-memory representation of
> the inode is not longer used, correct. However, the inode might still
> be allocated on-disk - unless unlink(2) has been called a number of
> times.

Of course the file isn't removed from the disk. The delete_inode call is used to
remove the in-memory inode representation when it's no longer needed, but the
name is somewhat of a misnomer. A file that has been unlinked is just one case
in which the in-memory inode isn't needed any more. In general, the 2.1 dcache
obviates the need for inode cacheing after i_count has been released.

> Please have a look at ext2_unlink: It decreases i_nlink, *not* i_count.
> Also, have a look at ext2_delete_inode:
> /*
> * Called at the last iput() if i_nlink is zero.
> */
> It then sets the dtime, truncates the file to zero size (freeing all
> blocks of the file) and frees the inode.
> delete_inode is called when the file ceases to exist, not when the
> last process has closed it.

A file system may choose to defer operations relating to removing the on-disk
representation to the delete_inode operation; it depends on the fs.

> OTOH, I want to clean up when the last process closes the file, and
> the system decides it will not longer cache the file. This does not
> mean the file is gone, it only means that the system won't need
> the data in-memory for a while.
> In short, delete_inode is the wrong place to return memory associated
> with an in-memory inode. With the current interface, there is no
> other place but put_inode.

If your cleanup operation blocks, then put_inode is the wrong place, because the
inode is still hashed and may go back into use after its state has been partly
destroyed. The delete_inode operation is always safe because the inode has been
unhashed. If you want to remove the inode from memory when i_count goes to 0,
then you can easily get to delete_inode from put_inode.

> I see that there is a potential for double-frees in the current NTFS
> code. However, I won't move clean-up to delete_inode - this will just
> buy me a huge memory leak.

No, delete_inode will work fine. Try it.