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
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

\
 
 \ /
  Last update: 2005-03-22 13:41    [from the cache]
©2003-2011 Jasper Spaans