I'm not sure whether you've been following the "extra per-inode data" and ntfs
clear_inode threads in linux-kernel, but we've been discussing the issue of
safely releasing inode resources at iput time. The proposal is to add a new
clear_inode sb operation to simplify cleanup, which would be called from
clear_inode(). This would allow the fs to free resources after the inode has
been unhashed to avoid races with re-use.
This can be handled with the existing interface using delete_inode, but it's not
very intuitive, and it becomes progressively more awkward as the filesystem
supports file deletion and uses the dirty-inode sync mechanism.
In the worst case situation, a fs with extra resources would have to perform the
following steps to safely cleanup:
(1) In put_inode at i_count == 1, save the current i_nlink in a private field
and set i_nlink to 0,
(2) In delete_inode, check whether the file is really being deleted or it's just
an inode cleanup,
(3) sync the inode if it's dirty,
(4) release resources
This assumes that the resource release may block, or that the resources can't be
reallocated later, making it infeasible use put_inode for the cleanup.
In the interest of making it easier to correctly and safely free inode
resources, I think it would be helpful to add a clear_inode sb operation for the
current 2.1.xx series. This will provide a simple way for the fs to release
resources without needing complicated logic in delete_inode.
For the longer term, I would like to see the inode code simplified further by
always disposing of the inode when i_count goes to 0, thereby avoiding the need
for the try_to_free_inodes logic. With the current dcache-centric cacheing, we
don't need to maintain an inode cache after the inode has been released. But
these changes should probably wait for the 2.3 tree.
Regards,
Bill