On Mon, 22 Mar 1999, Stephen C. Tweedie wrote:
> Hi,
>
> On Sat, 20 Mar 1999 15:46:18 -0500 (EST), Alexander Viro
> <[EMAIL PROTECTED]> said:
>
> > Folks, could somebody recall why the check for I_DIRTY had been
> > added to iput()? AFAICS it does nothing. If the inode is hashed and clean
> > it's already on inode_in_use, otherwise we are in *big* trouble (the only
> > reason for that might be crazy ->delete_inode() doing
> > insert_inode_hash().
>
> To maintain an LRU ordering for recently released inodes, I imagine.
> However, right now there's nothing I can see in inode.c which actually
> relies on that ordering: whenever we do a free_inodes(), we dump all
> the inodes that we can. In the future, having a sane LRU ordering on
> the in-use list may be valuable.
Oh, OK. That makes sense. I missed the reodering side-effect.
Thanks ;-)
In FAT fixes (I'll post the them for testing tomorrow or on
Wednesday) I actually needed a clear way to keep references to inode that
wouldn't affect i_count and related behaviour. I did it - it looks so:
1. Whenever we are scheduling the inode for freeing (free_inodes,
invalidate_inodes and two places in iput) we set I_FREEING in ->i_state.
2. I've added struct inode *igrab(struct inode*) that grabs the
spinlock, checks for I_FREEING, if it is set - releases the spinlock and
returns NULL, otherwise increases i_count, releases the spinlock, does
wait_on_inode() and returns the inode.
3. If fs wants to manage private references to struct inode it can
use igrab()/iput() to get/release a normal reference. It has to supply
->clear_inode() method and forget all private references to inode when it
is called. Some simple internal locking may be needed within the
filesystem, indeed. igrab() returning NULL should be processed as the case
when the reference was already invalidated by foo_clear_inode() call.
Changes to fs/inode.c are minimal (+10 lines) and do not affect
existing filesystems. If fs wants to keep an internal hash indexed *not*
by i_ino it can do it easily (e.g. FAT - we can keep i_ino constant over
the whole life of in-core inode and forget about bothering with 'busy'
directory slots. There go 20-odd races in FAT-derived filesystem + tons of
ugly code working around other 20-odd races). In case of FAT all code
needed to implement hash indexed by directory entry position + glue for
clear interaction with icache took about 40 lines. *And* allowed to remove
much more cruft.
So there...
Cheers,
Al
