On Mon, 19 February 2007 21:06:33 -0600, Dave Kleikamp wrote:
>
> You've obviously given this a lot more thought that I have, but this
> sounds like something that has possibilities. You couldn't implement
> your own drop_inode method that does better locking against the garbage
> collector?
Bloody hell! What a great question for an unexpected reason. GC also
races against iput().
Basically whenever anyone locks any inode, I may have a problem. If
that inode remains locked until some writeout happens, I will have a
problem. Afaics, locking happens in three places:
__sync_single_inode()
Causes writeout of inode pages and inode itself
iput()
Causes writeout of inode itself
get_new_inode() or get_new_inode_fast()
No writes from here
Both __sync_single_inode() and iput() would need to prevent GC before
locking the inode. GC can be caused by any writes to LogFS, so they
need to lock against all write paths in LogFS. Once they start writeout
themselves, they also need to pass information that they have taken the
lock onward, otherwise taking the lock itself would deadlock. Nasty.
Alternatively there could be a non-blocking version of iget() that
simply returns when an inode is locked. Now GC would have to spin in a
loop, waiting for one of two possible events. Either the inode is
getting unlocked or someone calls into LogFS with the inode in question
and GC needs to take that by some means. Again, nasty.
The more I think about it, the more I like the idea of double-caching
inodes. As ugly as it sounds, it causes the least amount of problems.
Thanks, Shaggy!
Jörn
--
Linux [...] existed just for discussion between people who wanted
to show off how geeky they were.
-- Rob Enderle
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
