Messages in this thread | | | Date | Sat, 31 Jan 1998 00:31:04 +0100 | From | Martin von Loewis <> | Subject | Re: 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
| |