If delayed atime is implemented correctly, this shouldn't happen. The
inodes will sit in memory until we need the memory for something else;
if your recursive diff doesn't thrash the disk cache, you're fine. If
it does thrash the cache, you were going to lose anyway.
Hmm... looking at fs/inode.c, we could do this by setting
inode->i_state & I_DIRTY in update_atime, but leaving it on the
in-use list. __mark_inode_dirty would have to move to the dirty list
irrespective of whether I_DIRTY was set or not, and we'd have to make
sure this didn't cause problems in clear_inode etc.
Incidentally: mark_inode_dirty checks i_state & I_DIRTY, then calls
__mark_inode_dirty, which grabs the inode_lock and checks it again.
Is the second check necessary?
zw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/