Re: Using ilookup?

[Charles Manning <manningc2@actrix.gen.nz>]

On Wednesday 13 October 2004 18:50, Andreas Dilger wrote:
> On Oct 13, 2004  14:42 +1300, Charles Manning wrote:
> > YAFFS allocates its own "objectId"s which are used as inode numbers for
> > most purposes. When objects get deleted (== unlinked), the object numbers
> > get recycles.  Sometimes though the Linux cache has an inode after the
> > object has been deleted. Then if that object id gets recycled before the
> > cached inode is released, a problem occurs since iget() gets the old
> > inode instead of creating a new one. We then end up with an
> > inconsistency.
>
> You can use iget4() along with a filesystem-specific comparison function,
> which allows you to distinguish inodes with the same number based on
> some extra data (e.g. generation number, 64-bit inode numbers, etc).  Is
> there a reason to recycle the inode numbers, or could you just have a
> 32-bit counter?

The problem, I believe, with iget4() is that this will make a new inode if 
one does not exist which seems to be more running around than I really want 
(especially since in most cases the inode will not exist).

The number space is 18 bits, but even with 32 bits incrementing through the 
list will not make the problem go away, just reduce it to a very small 
probability.

>
> > 1)  Somehow plug myself into the inode iput() chain so that I know when
> > an inode is removed from the cache. I can then make sure that I don't
> > free up the inode number for reuse until the inode is not in the cache.
> > Any hints on how to do that?
>
> You can use the ->delete_inode method which is a hook to be called
> before/instead of the clear_inode() function in iput(), and is
> the last thing action taken when the inode is being unlinked.  There
> is also the ->clear_inode inode method, which is called when inodes
> are being put away but not only when being unlinked.

It seems to me that delete_inode() is the place to hook into. I already use 
this for regular files, I just need to extend this to directories, pipes and 
other specials.

I knew about the regular file case because you can do things like:

  f= open("xx"...);; /
 unlink("xx");  // file no longer exists in directory, but still exists 
 read(f...)
 write(f...)
 close(f) ; // file disappears from disk.

I did npt realise that you could essentially achieve the same thing with 
directories, pipes and other specials.

Thanks for the help.

-- Charles