Messages in this thread | | | Date | Fri, 30 Jan 1998 08:14:41 -0500 | From | Bill Hawes <> | Subject | Re: Extra per-inode data |
| |
Martin von Loewis wrote:
> 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
| |