Re: VM deadlock

Andrew Morton (andrewm@uow.edu.au)
Thu, 28 Jun 2001 13:21:28 +1000


Chris Mason wrote:
>
> ...
> The work around I've been using is the dirty_inode method. Whenever
> mark_inode_dirty is called, reiserfs logs the dirty inode. This means
> inode changes are _always_ reflected in the buffer cache right away, and
> the inode itself is never actually dirty.

reiserfs_mark_inode_dirty() has taken a copy of the in-core inode, so
it can do this:

spin_lock(&inode_lock);
if ((inode->i_state & I_LOCK) == 0)
inode->i_state &= ~(I_DIRTY_SYNC|I_DIRTY_DATASYNC);
spin_unlock(&inode_lock);

Unfortunately there is no API function to do this, so inode_lock
needs to be exported :(

The effect of this is that the filesystem almost never has dirty inodes
as far as the VFS is concerned: shrink_icache_memory() can just drop the
inodes without calling into the fs at all. Which is nice.

So you end up with:

reiserfs_write_inode(struct inode * inode, int do_sync)
{
}

The write_inode() method is still called by shrink_icache_memory()
with extreme infrequency. I haven't looked into the reasons why. It may
be an SMP window.

This is not just a memory-tweak-optimisation hack, BTW.
shrink_icache->write_inode is a horrible embarrassment because it
can be called at any time. The caller may have a transaction open
against a different fs. It would cause nested transactions which
will exceed the current reservation, which will require a commit,
which simply cannot be performed, etc.

sync(), fsync() and msync() can be handled in ->fsync().

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