[lkml]   [1998]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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.


     \ /
      Last update: 2005-03-22 13:41    [W:0.019 / U:20.948 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site