> Hmm. delete_inode is called only when i_nlink is zero. As this is
> meant to be the hard link count, delete_inode is really the operation
> that gets called when the file system should return the physical inode
> into the free inode pool.
>
> Also, delete_inode won't be called if there are still hard links to
> the file. Faking the hard link count to zero in put_inode also does
> not work, because you then don't know anymore what the count is inside
> delete_inode, and because there might still be users of the file.
Hi Martin,
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.
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.
Cleanup operations can be done in put_inode if they don't block, but a blocking
operation would allow the inode to be reused after some of its resources have
been freed. This was a cause of many race problems in the 2.0.xx series, but can
be completely avoided in 2.1.xx by deferring cleanup to delete_inode. Once the
inode has been unhashed, it can't be reused and the cleanup is completely safe.
This is not to argue against the idea of adding a clear_inode operation -- I'm
just pointing out that in most cases you can use the existing put_inode and
delete_inode to accomplish your end.
Regards,
Bill