Messages in this thread | | | Date | Fri, 30 Jan 1998 21:17:22 -0500 | From | Bill Hawes <> | Subject | Re: Extra per-inode data |
| |
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 inode.
> 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.
Regards, Bill
| |