lkml.org 
[lkml]   [1998]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Extra per-inode data
> If there are still active hard links to the file, put_inode won't have an
> i_count of 1, as the other dentries are holding the use count for the other
> paths to the inode.

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.

> The reason to force a call to delete_inode from put_inode is that we
> _do_ want to free the physical inode -- otherwise the dentry layer
> wouldn't have released the inode. Once i_count is going to 0,
> there's no need to keep the inode around.

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.

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.

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.

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.

Regards,
Martin

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.047 / U:1.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site