Re: Using ilookup?

[David Woodhouse]

On Wed, 2004-10-13 at 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. 

Stop there... _why_ is the inode still in the icache after the object
has been deleted? It sounds like this is your real problem. Once the
last link to it goes, and the last file handle to it is closed, it
should be gone immediately. 

It sounds like you're doing too much in your unlink method. The object
isn't necessarily dead at the time you unlink it -- it could still be
open. You just decrement its nlink and wait for the VFS to tell you it's
done with it.

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

->clear_inode() or ->delete_inode() as Andreas said.

> 2) When creating inode numbers, I could test for if there is a corresponding 
> inode in the cache first and just not recycle that number if there is. To do 
> this is ilookup the correct/safe thing to do?

It's safe but it doesn't sound correct. It sounds like a workaround for
the real problem.

> 2') A further issue here is that ilookup is not available in some older 2.4.x 
> versions. Is it Ok to just patch the ilookup code in, say, 2.4.27 back into 
> earlier versions (say 2.4.18 which seems a popular vintage for embedded stuff 
> for some reason or other).

No. If these people want new file systems and new features in code code,
why on earth are they still using 2.4.18? They should be on 2.6, or at
_least_ current 2.4 kernels. I could sort of understand if they've had a
lot of testing in the two and a half years since 2.4.18 was released and
they don't want to change _anything_.... but that obviously isn't the
case if they're adding new stuff like this.

-- 
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/