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
> Generally it's better to do clean up in delete_inode, as at that
> point the inode has been unhashed and can't be reused. The call to
> clear_inode should go in delete_inode.

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.

So *if* you want to return memory associated with the struct inode,
you currently really have to do this in put_inode. With the current
code, a test for i_count==1 would be required, though.

In any case, since the semantics if put_inode was changed (it is now
called on each iput, not only on the very last one), we apparently
need another operation for the last iput, which should be different
from delete_inode.

Regards,
Martin

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.067 / U:0.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site